💾 Archived View for rawtext.club › ~sloum › geminilist › 005839.gmi captured on 2023-11-14 at 09:49:31. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
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 notindicate how big a given response is, mimicking gopher and the very earlyHTTP protocol. In gopher with a non-binary file being transferred, a "." ona line by itself indicates "end-of-file" and for binary files, it's up tothe client to keep reading until the stream is closed (RFC-1436 states asmuch: " Note that for type 5 or type 9 the client must be prepared to readuntil the connection closes. There will be no period at the end of the file..."). Gemini inherited this model and no attempts to include a reponsesize has been accepted.
So, all a client has to go by in Gemini that a file was sent correctly, isto 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 twoendpoints (a router crash) are caught, as well as the server crashing beforeit 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 theclient. Also, it was never an expectation that the client close its sideafter making a request.
Hopefully, this provides enough background on this topic from a Geminiperspective.
-spc