3 ms·

I share your concern. 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 g

I share your concern. 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.

gray_-_wolf 6y ago
But since they explicitely state that it is not suitable for large content, server could just cache it until it has it all. Most clients will likely wait for whole response anyway. 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.
- UIZealot 6y ago
  I agree that always sending content-length would be ideal, if it didn't come with the extra work and costs on the server that you mentioned. 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.