Content length, EOF -- ways to resolve whether we received everything

[Björn Wärmedal]

There's been a lot of discussions about the lack of an end-of-message
indicator in the protocol. Clearly it's something that a lot of client and
server implementers are missing.

A proposal that arose (I think acdw may have been the first to suggest it;
correct me if I'm wrong) was to include a "content-length: <nr of bytes>"
in the <META> of a status 20 response. It's a simple thing to add, that
doesn't extend the protocol into bloat.

"But, ew0k! The <META> is for MIME types! That's not a MIME type!"

Yes, this is true. Would that cause an issue? In that case calling it
"x-gemi-content-length" should resolve it, as the "x-" prefix is for
experimental types and any receiver that doesn't recognize it will ignore
it. I'm aware that it still doesn't convey info on the *type* of content,
and thereby doesn't belong among MIME type info, but it's a compromise I'm
willing to make.

Are you?

Cheers,
BW/ew0k
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201030/a9a59223/attachment.htm>