💾 Archived View for rawtext.club › ~sloum › geminilist › 001746.gmi captured on 2020-11-07 at 02:26:32. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

HTTP/0.95 - the sweet spot or thereabouts?

Luke Emmet luke at marmaladefoo.com

Tue Jun 16 20:21:51 BST 2020

- - - - - - - - - - - - - - - - - - -

Hi everyone

Just to toss a couple of things into the debate, for those interested in a minimal application capability for Gemini, but don't want all the bells, whistles and complexity of what the web became (cue scary music)

I did a bit of digging on the background history of HTTP. Maybe you are all familiar with this, but personally I found it quite illuminating on our conversation. If we are positioning Gemini between Gopher and the Web, we can decide where is the sweet spot along the spectrum.

https://medium.com/platform-engineer/evolution-of-http-69cfe6531ba0

https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP

https://hpbn.co/brief-history-of-http/

HTTP 1.1 was the first fully standardised version, having an extensible structure, and many possible headers, cookies etc. However before that there were two pre-standardisation version that are quite interesting to look at.

== HTTP 0.9 ==

This was the very first version designed by Berners Lee. All it had was GET (sound familiar?)

Modulo the certificates/TLS stuff in Gemini, it is more or less what Gemini is right now.

If you just want idempotent resources and nothing else, this is all you need and is what we have in Gemini at the moment.

== HTTP 1.0 ==

This introduced two other methods HEAD (a GET with no response body) and POST which is for sending content to the server. It was still one connection per resource. It defined URL format, charsets and mime types and the idea of a header format and some standard headers (Content-Length, Date, Others).

It also defined a mechanism to create new arbitrary headers (we can get rid of that)

== HTTP 1.1 ==

The first fully standardised version that really took off and had a million different options including persistent connections, cookies and so on. This is too much for our needs and the extensibility opened the door to all the sugary complexity we are trying to avoid.

_________

Looking at HTTP 1.0, it seems to mirror the basic needs for Gemini to be able to be used as a platform without the bloat that became 1.1, 2.0 (and in the future 3.0/QUIC is in discussion)

My sense is we can find the sweet spot at about "HTTP 0.95" which is enough to support application development without the cruft of arbitrary headers and extensibility.

Here is the RFC for HTTP 1.0:

https://tools.ietf.org/html/rfc1945

quoting from the RFC about POST:

The POST method is used to request that the destination server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:

o Annotation of existing resources;

o Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;

o Providing a block of data, such as the result of submitting a form, to a data-handling process;

o Extending a database through an append operation.

The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.

<continues

A valid Content-Length is required on all HTTP/1.0 POST requests. An HTTP/1.0 server should respond with a 400 (bad request) message if it cannot determine the length of the request message's content.

Applications must not cache responses to a POST request because the application has no way of knowing that the server would return an equivalent response on some future request.

This seems to well describe the needs of building non-idempotent applications in Gemini.As per previous emails we dont need the full vocabulary of the other HTTP verbs such as DELETE/PUT etcand we can also still dispense with HEAD (a body-less GET) as adding not much (and was not much used).Clients can implement a simplistic form of HEAD by abandoning a connection after the header line is seen.

So what I think we need is something around HTTP 0.95 (it never existed) which is about half way between HTTP 0.9 and 1.0.

GET (gemini right now)POST (for non-idempotent interactions)Content-Length indicator (to make POST work)

no other headers, so not extensible, so not as far as HTTP 1.0, but allows application development.

I'll leave you in peace now :-)

- Luke