[announce] Delegation of responsibility for spec finalisation

Sean Conner sean at conman.org
Tue Mar 2 02:13:34 GMT 2021

  To give the "TLS close" issue some context:  The Gemini protocol does not
indicate how big a given response is, mimicking gopher and the very early
HTTP protocol.  In gopher with a non-binary file being transferred, a "." on
a line by itself indicates "end-of-file" and for binary files, it's up to
the client to keep reading until the stream is closed (RFC-1436 states as
much: " Note that for type 5 or type 9 the client must be prepared to read
until the connection closes.  There will be no period at the end of the file
...").  Gemini inherited this model and no attempts to include a reponse
size has been accepted.

  So, all a client has to go by in Gemini that a file was sent correctly, is
to wait for the server to close its side of the connection, as signaled by a
"TLS close".  This means that issues with the network between the two
endpoints (a router crash) are caught, as well as the server crashing before
it can send a "TLS close."

  Then someone noticed that TLS include semantics of "this side is closed"
and thus, why the server is expected to close the connection, not the
client.  Also, it was never an expectation that the client close its side
after making a request.

  Hopefully, this provides enough background on this topic from a Gemini


More information about the Gemini mailing list