💾 Archived View for rawtext.club › ~sloum › geminilist › 000760.gmi captured on 2020-11-07 at 01:44:43. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Questions regarding "POST" request and line endings

solderpunk solderpunk at SDF.ORG
Sun May 17 14:27:12 BST 2020
- - - - - - - - - - - - - - - - - - - ```

On Sun, May 17, 2020 at 02:55:03PM +0200, Felix Quei?ner wrote: 
> I wanted to ask (and maybe discuss, if not done already) why Gemini has
> no option to upload a file to a server except for a roughly 1024 byte
> long URL string.

I have to admit, this idea has occasionally crossed my mind.  Mostrecently, when Dave wrote a helper for Git so that people could `gitpull` over Gemini, which I thought was super cool - `git push` isn'tpossible with Gemini as a read-only protocol.

It's not that I don't think there are good uses for this.

The original reason is that I was obsessed from day one with making itextremely hard for people to be able to extend the core Gemini protocol.HTTP, for example, allows as many headers as you like inrequests/responses.  Clients are expected to read them all, and handlethe ones they can handle.  This means anybody can come up with a newheader, and if it's popular many clients/servers will implement it, andthen it becomes a de facto part of the standard, and clients/serverswhich don't handle it are seen as "broken" or "primitive".

This extensibility is of course a useful thing in many ways from anengineering perspective.  But in the long term it is, IMHO, fundamentalytotally incompatible with ideals like simplicity and minimalism andprivacy and "anybody can implement it themselves over a weekend in <1000 LOC".  Designers of protocols which are extensible effectively losea lot of control over their protocol.  It's pointless me trying veryhard to keep stuff which could be abused for tracking out of Gemini ifit can be snuck in by popular consensus this way, because inevitably itwill be.  You've just got to limit the scope for this kind of extensioneverywhere you can.

If you take this idea seriously, you are basically forced to chooseone kind of "thing" a lot, and then have that thing be totally implicit.If there's only one kind of Gemini request (something analogous to GET),then we don't have to explicitly put anything in the request formatsaying "this is a GET-ish request".  And if there's nothing explicitthere, nobody can write an "advanced" server which recognises adifferent value in that place.

So, thinking from a perspective of simplifying HTTP, I had to chooseonly one method, so I chose GET.  I had to choose only one responseheader, so I chose Content-type (because my experience maintaining apopular Gopher client convinced me this was the most sorely lacking bitof information).  Several people convinced me to use full blown URLsinstead of just paths as I originally specced for requests, which isequivalent to choosing Host as the only request header.  Basically thistheme runs deep all throughout Gemini's design: wherever HTTP allowsseveral things, pick the one most fundamentally important/useful one,and make it an implicit default with no scope for anything else.

If somebody can come up with a way to distinguish GET from POST stylerequests without also opening up an obvious door to arbitrarily manyextra request types, I'll give it some thought.  But I'm not optimistic.

Insisting on non-extensibility necessarily imposes limits on how muchGemini can do.  That's okay.  Limitations encourage creativity, and givedifferent things their own unique style/taste/whatever.  Gemini is nevergoing to be able to do everything that the web can do - it can'tpossibly do that while remaining simpler.  We should accept this. > Another question:
> Why does gemini use <CR><LF> line endings instead of a single <LF> or
> <CR> token? It makes the parser implementation more complex and imho
> brings no benefit to the protocol and text format itself. I see no
> reason why i should have a single <CR> or <LF> in a line and it may
> confuse users: "12345, World!<CR>Hello" may be printed as "Hello,
> World!" on most text terminals which is imho undesirable for
> non-interactive output.

As recently mentioned, the spec doesn't actually explicitly say anythingabout line endings in text/gemini content itself (although it should).It does suggest that CRLF is needed at the end of =
> lines, but that wasunintentional on my part.  I agree that requiring CRLF for actualcontent is strange and I suspect this will change in the next revision.

CRLF *is* clearly and deliberately specced in the non-content part ofthe protocol, i.e. for requests and response headers.  And the honestanswer here is, well, that's how every internet protocol whose spec I'veever looked at works - HTTP, Gopher, SMTP, IRC, for example, all dothis.  I admit to being ignorant as to the exact historical reason for his convention.  But it's a deep and wide convention adhered to bypeople who know more than I do, and for that reason I'm reluctant tobreak it without very good reason.

If people have strong feelings in either direction about the lineterminator to be used in the protocol and in text/gemini content, I'mvery happy to hear it.

Cheers,Solderpunk