OETF #17 - Open HyperText Protocol

[Zen1th 14]

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 /foo.bar (the PAGE entry CANNOT BE EMPTY, if wanting to access default file of server, use /):

OHTP/1.0 GET /foo.bar

Currently the valid REQUEST values are:

• GET (just receive the file)
• UPLOAD (part of upcoming OHTP 1.1 document, will be used to upload files if the Client has permissions)

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>

 

[Zen1th 14]

I updated OHML, i added bodys, user agents and peanuts (equivalent of cookies). It's still called version 1, since actually nobody implemented it yet. So changes to v1 were still open. Now version 1 is froze. Promised!

[EveryOS 0]

On 4/13/2019 at 4:45 AM, Zen1th said:

OHTP PORT SHOULD BE 80

 

I am using a URL parser that allows for the specification of specific ports (e.g `ohtp://example:80/`). What should I do if the user chooses a port besides 80?

[Zen1th 14]

You can use the port that is not 80. since i said "SHOULD" and not "MUST". But i'll try to change this for better clarity