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

[Arav K.]

On Fri Oct 30, 2020 at 2:38 PM WAT, John Cowan wrote:
> I confess to not having read these discussions. But what's the
> problem?  The server writes an entity-body to the socket and closes
> it. The client reads from the socket until it gets EOF (a zero-length
> return from read or recv). Done. Gopher has been transmitting binary
> files like this forever, and the cognate protocols finger and whois
> also do it this way: no length or in-band EOF sequence.

The problem is that clients have no way to know how much stuff they're
receiving.  This would be helpful for interactive clients, so that they
can tell the user some indication of progress, and it would be helpful
for more constrained programs to know whether or not they can store all
their input.  Both of these points were raised in previous discussions.

> It is the particular mime-type that declares what parameters are
> meaningful to it. Writing
> "text/plain;charset=utf-8;content-length=32767" will not mean anything
> to anyone outside the Gemini world and will probably confuse them.

AFAIK, all MIME parsers know to ignore additional MIME parameters.  Even
if someone who did not know about this concept were to see such an MIME
type, the idea is clear.  I don't see how including this is a problem.

~aravk | ~nothien