💾 Archived View for rawtext.club › ~sloum › geminilist › 007680.gmi captured on 2023-11-14 at 08:25:03. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-09-08)
-=-=-=-=-=-=-
Luke Emmet luke at marmaladefoo.com
Mon Dec 13 17:13:06 GMT 2021
- - - - - - - - - - - - - - - - - - -
Hello
(we are straying off the thread a bit so I've tweaked the subject)
On 13-Dec-2021 11:21, Krixano wrote:
Now, about what the spec states. If you read the spec too literally and linearly, then I can kinda see how people might think the spec says requests must be handled after close_notify, from:
C: Opens connection
S: Accepts connection
C/S: Complete TLS handshake (see section 4)
C: Validates server certificate (see 4.2)
C: Sends request (one CRLF terminated line) (see section 2)
S: Sends response header (one CRLF terminated line), closes connection
under non-success conditions (see 3.1 and 3.2)
S: Sends response body (text or binary data) (see 3.3)
S: Closes connection (including TLS close_notify, see section 4)
C: Handles response (see 3.4)
I firmly believe that this is an undesired overly-linear interpretation, and that perhaps Solderpunk might want to consider changing this if necessary, and if his views on streaming haven't changed. Remember, the spec isn't actually final yet.
Yes there would be an ambiguity in the spec if streaming clients are expected or normative. Personally I think it is intentional that the spec aims to keep the complexity of implementation low, as that is in keeping with the rest of Gemini's design approach. Implementing a streaming client is more complex, and there are more cases that would need to be specified to resolve protocol ambiguity. For example how does a client tell the difference between a poorly behaved server that is just dripping a few bytes out second by second and one that is a streaming service? I can't see how it can, particularly given that there are no content-length headers in Gemini.
The Gemini FAQ also hints towards this simplicity and says Gemini is not suited to large downloads
"2.6 Does Gemini have any shortcomings of it's own? Naturally! Gemini has no support for caching, compression, or resumption of interrupted downloads. As such, it's not very well suited to distributing large files, for values of "large" which depend upon the speed and reliability of your network connection."
At present the spec says the client waits for the content then handles the response.
So this is what the spec says at present, it doesn't say that clients may expect that server streams are indefinite in length.
We have previously discussed this and there was some useful thoughts written up by James Tomasino
https://lists.orbitalfox.eu/archives/gemini/2020/002404.html
My view is that if you want to stream content, there are better protocols available (e.g. HTTP and others).
Best wishes
- Luke