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

[Ivy Foster]

On 30 Oct 2020, at 12:50 pm +0100, Björn Wärmedal wrote:
> 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.

Alternately, as I [previously pointed out][1], there is [an
established RFC][2] for including size as a parameter to a MIME type.
Specifically, it's part of the specification for email: if any
"attachment" is actually an external part to be fetched rather than an
actual attachment, you specify
"content-type:foo/bar;access-type:how-you-get-it;(optionally)size:octets".
Solderpunk did shoot it down, granted, but since the conversation's
come up again I figure I should point this out instead of having us
come up with new MIME extensions.

[1]: https://lists.orbitalfox.eu/archives/gemini/2020/001534.html
[2]: https://tools.ietf.org/html/rfc1341