A discussion took place in August that was revisited on IRC today: gemini://gemi.dev/gemini-mailing-list/messages/002404.gmi I disagree very strongly with the suggestion of gemini+stream://. It relies upon a presumption about the specification which is poorly supported: that all Gemini requests are finite. The supporting text for this is supposedly that section 1.1 lists "C: Handles response" last. However: 1. Section 1.1 reads like an informative summary of the authoritative text which follows 2. There is no explicit specification that these steps are ordered or cannot be completed in parallel, and aren't even numbered. The other relevant piece of text is in 3.3: > The server closes the connection after the final byte, there is no > "end of response" signal like gopher's lonely dot. There is no statement anywhere that there actually has to *be* a final byte; only a clarification on how the final byte is signalled if present. Nothing in the specification prohibits Gemini responses from being non-finite, and in fact if clients presume this will be the case then they'll be easily exploited by servers which simply forward /dev/zero into the connection and never terminate, leading to OOM crashes or disk space exhaustion. If you want to stream content, the protocol permits it as-is. And remember the one big rule: Do not. Extend. Gemini.
---