Questions regarding "POST" request and line endings

[solderpunk]

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.  Most
recently, when Dave wrote a helper for Git so that people could `git
pull` over Gemini, which I thought was super cool - `git push` isn't
possible 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 it
extremely hard for people to be able to extend the core Gemini protocol.
HTTP, for example, allows as many headers as you like in
requests/responses.  Clients are expected to read them all, and handle
the ones they can handle.  This means anybody can come up with a new
header, and if it's popular many clients/servers will implement it, and
then it becomes a de facto part of the standard, and clients/servers
which don't handle it are seen as "broken" or "primitive".

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

If you take this idea seriously, you are basically forced to choose
one 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 format
saying "this is a GET-ish request".  And if there's nothing explicit
there, nobody can write an "advanced" server which recognises a
different value in that place.

So, thinking from a perspective of simplifying HTTP, I had to choose
only one method, so I chose GET.  I had to choose only one response
header, so I chose Content-type (because my experience maintaining a
popular Gopher client convinced me this was the most sorely lacking bit
of information).  Several people convinced me to use full blown URLs
instead of just paths as I originally specced for requests, which is
equivalent to choosing Host as the only request header.  Basically this
theme runs deep all throughout Gemini's design: wherever HTTP allows
several 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 style
requests without also opening up an obvious door to arbitrarily many
extra request types, I'll give it some thought.  But I'm not optimistic.

Insisting on non-extensibility necessarily imposes limits on how much
Gemini can do.  That's okay.  Limitations encourage creativity, and give
different things their own unique style/taste/whatever.  Gemini is never
going to be able to do everything that the web can do - it can't
possibly 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 anything
about line endings in text/gemini content itself (although it should).
It does suggest that CRLF is needed at the end of => lines, but that was
unintentional on my part.  I agree that requiring CRLF for actual
content is strange and I suspect this will change in the next revision.

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

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

Cheers,
Solderpunk