Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal

Search the Community

Showing results for tags 'ohml'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • OpenComputers
    • Announcements
    • Feedback
    • IRC
  • Code Central
    • Support
    • Showcase
    • Tutorials
  • Addons & More
    • Addons Mods
    • Architectures
    • OpenEngineering Task Force
  • General
    • Lounge
    • Forum Games
    • Showcase
    • Servers
  • Archives
    • Public Archives

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL










Found 1 result

  1. 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. 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 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. 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 PORT IS 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. 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 Yep, i know it's really small, making it simple to implement. Currently there are thoses error codes: 200: OK 201: Moved permanently + new URL after ERRORCODE 300: Temporaly moved + new URL after ERRORCODE 301: Switch protocol + approved protocol name after ERRORCODE 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: As specifying OC content types would require a whole new topic. Can just be equals to "page", "resource" or "download". Page is OHML, Resource are resources like images, and download is everything meant for download (Lua files, installers, compressed files, etc.) 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 A LINE BREAK (\n) Example Response (whole): 200 Set-Peanut: isadmin=true Content-Type: page <ohml> <text>Hello World!</text> </ohml>
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.