> The server closes the connection after the final byte, there is no "end of response" signal like gopher's lonely dot.
This just seems like a bad idea, especially if one is on shitty connection.
Since the response body is not encoded, there's no safe end-of-response marker byte(s) to use.
So content-length seems like the way to go. But knowing content-length ahead of time is difficult for dynamically generated content (CGI is supported after all), so they also need something similar to HTTP chunked encoding, which does complicate things a little.
I understand that keeping the Gemini client simple to implement is one of their design goals, but I don't think the same is true for the Gemini server. So I hope that they would consider adding these to the protocol. They could probably stuff the content-length or the word "chunked" in the <META> string.
I feel like that would strike reasonable balance. Client are still simple (arguably more simple since they don't have to guess if they got everything) and the protocol is still trivial. For dynamic content, it would increase time-to-first-byte and ram usage on server, but both imho would not be an issue for the type of content gemini aims for.
Chunked encoding is simple enough to implement, avoids all those issues, and would allow a Gemini server to serve more requests faster given the same resources, or to run on hardware with more limited resources such as embedded. So I think it's well worth the slight cost in simplicity.