Search the Community
Showing results for tags 'ohml'.
Found 1 result
OHML being complete, it just needed something next so the OHML specification is complete. And this thing is what is here: OHTP Definitions: Host - Any computer or machine with a OC-compatible modem attached to it Server - Host sending OHTP-valid data when an user attemps to connect Client - Host receiving OHTP-valid data from a Server OHTP - Open Hyper Text Protocol - Protocol used to transmit OHML - Open Hypertext Markup Language between Hosts. Line Break - Unix style line break: line feed (\n) Specifications: The OHTP protocol doesn't take care of what is transporting it. Either it is using a socket API, going through modem, minitel or GERT. It assumes the API or transport layer you utilize supports sockets. Arguments in URLs: To put arguments inside URL, the url must end like normal, but have "?" at end, followed by "property=value" entry. If wanting to add more entries, add "&" after last entry Example: ohtp://1001.1002:1003.1004/index.ohml?username=admin&password=admin writeTable/readTable, Fuchas's liblon, etc. User Agents: User agents are standard strings defining what browser and what layout engine a user is using. It can be used for metrics and/or compatibility purposes (in case standards aren't fully respected). An user agent is presented in the following form: BrowserName/BrowserVersion, LayoutEngine/LayoutEngineVersion where LayoutEngine is the layout engine and LayoutEngineVersion is layout engine's version, etc. The format has been thinked to be simple making it easy to parse. Since it's just 2 fields separated with a "," (Browser name and version + Layout engine name and version), and in those fields, the name and version separated with a slash (/). Parsing user agent is in this case, just some splitting of strings. For example with Icecap browser (coming soon): Icecap/0.1, Geeko/1.0 Peanuts: Peanuts are data stored as text files in a key=value scheme. They are handled on client-side and are only edited by server. He edits it by sending a response property (Set-Peanut) to client. A Peanut Group (peanuts) is separated by ";". Making ";" the only invalid character in peanut key and value. Server is aware of Client peanuts by the Peanut request property. Which sends peanuts as a Peanut Group. Of course this property is optional as a client doesn't always have peanuts. Now the most important note about peanuts: When a server send a Set-Peanut property. The peanut must be set for the whole website and not only the current page! Connection: OHTP DEFAULT Port SHOULD be 80 Client-Side: Once the socket is opened, the Client can ask data to Server The Client will send first a Request Header looking like it: OHTP/MAJOR.MINOR REQUEST PAGE Example, if the REQUEST is GET, and the version 1.0, with a request page equals to /index.html (the PAGE entry CANNOT BE EMPTY, if wanting to access default file of server, use /): OHTP/1.0 GET /index.html Currently the valid REQUEST values are: GET (just receive the file) There are also request bodies, which just include "Property: Value" entries. Non-standard properties, must start with "X-" Standard Properties: Standard properties are for now: Peanut - Inform server of currently saved peanuts (see Peanuts) User-Agent - User Agent of the current browser (see User Agents) Referer - If redirected from a link, equals to the previous website URL. Host - The hostname the browser used to connect to this website. This let the website know how it is identified. Useful for 300/301 error codes. So a request is constructed like that: Request Header( + Request Body) The client, even after having received the Response from Server can still send new requests. All that until socket is closed. Example Request (whole): OHTP/1.0 GET /index.ohml User-Agent: MineScape/1.0, Geeko/0.9 Peanut: login=true;username=admin;password=admin X-Non-Standard-Header: non standard value Server-Side: Once the Server receives a Request from a client. It must replies with a Response. A Response is contructed like this: Response Header + Response Content The Response Header is constructed like this: ERRORCODE Response Body Response Content It's really small, making it simple to implement. Currently there are thoses error codes: 200: OK 300: Temporaly moved + new URI after ERRORCODE. The browser will redirect to the URI but is unable to cache. 301: Moved permanently + new URI after ERRORCODE (ex: 301 ohtp2://thismachine). The browser will redirect to the URI and can cache it. Best used with Host property. 302: Switch protocol (e.g.: 301 OHTP2) + approved protocol name after ERRORCODE 303: Switch network protocol (e.g.: 302 minitel) + approved protocol name after ERRORCODE 403: Invalid request 404: Page not found 500: Server error 501: Internal error sending the the fetched page (e.g. file found but not accessible from server). 502: Server-side language is errored (Detailled version of 500, optional) 503: Service temporaly down The Response Body is just a bunch of standard properties exactly like in the client-side request body. However the valid properties changes for Server. Standard Properties: Set-Peanut: Sets a peanut on client. Content-Size: The size of the content. Useful for long downloads! Content-Type: The MMTI identifier for the corresponding resources. If not found, defaults to "text/txt" Like Request properties, unstandard ones start with "X-" The Response Content is just the content of the fetched file (if found). THE RESPONSE CONTENT MUST BE SEPARATED FROM RESPONSE BODY WITH TWO LINE BREAK (\n\n) Example Response (whole): 200 Set-Peanut: isadmin=true Content-Type: text/ohml <ohml> <text>Hello World!</text> </ohml>