💾 Archived View for jsreed5.org › log › 2024 › 202405 › 20240531-gemini-and-content-length.gmi captured on 2024-08-18 at 18:01:12. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-07-08)
-=-=-=-=-=-=-
---
Gemini is rife with discussions about missing features and options that, if only solderpunk had enough foresight to include, would surely make the protocol render the modern Web unnecessary. I don't want this post to be another persuasive essay drowning in the mire, but I do want to make one observation.
Out of all the features the Gemini protocol forgoes, the one I find most interesting is content length. Gemini was conceived as a single-request protocol: once the server sends a response code and optional response body, it closes the connection and sends a TLS close_notify. This implies to me that Gemini requests normally expect the server to close the connection first (as opposed to the client), and if so, the server would likely know ahead of time how much data is meant to be sent to the client and could relay that information in a response header.
That Gemini does not do this, combined with the fact that the spec allows clients to start processing responses before the server closes the connection, allows for an unexpected feature: Gemini does support a rudimentary form of streaming. Some services already use this feature, though it does not seem to be widespread. I don't think Gemini's streaming capabilities are a good idea in the long term, but I have no argument with those who use it. I will simply avoid implementing it on my own capsule.
I assume Gemini doesn't include content length because Gopher does not include content length. Gemini takes many such design clues from Gopher, which is why I feel it is better described as an expansion of Gopher rather than a reduction from HTML.
---
[Last updated: 2024-06-28]