Reopening: Stream status code

Philip Linde linde.philip at gmail.com
Fri Jul 31 11:25:20 BST 2020


On Fri, 31 Jul 2020 12:03:42 +0200
Katarina Eriksson <gmym at coopdot.com> wrote:
> Are you proposing adding content lenght to the MIME type? That has been
> rejected every time the topic has come up and has led to the discussion of
> alternative ways to communicate such meta data.

No, I'm suggesting in general a protocol-level way of communicating in
advance how many bytes will follow the header. I am not aware that MIME
types can be used for that purpose.

> The point is to not have an extendable header.

The header needn't be extensible to support this. It could be a
required part of the header (my original thinking, hence admitting that
this is quite a radical change) or it could be optional in the same way
that the MIME type is optional (which would not be nearly as useful and
probably would still break a fair amount of existing clients, but
would at least not require a change on servers).

The purpose would be to give clients some information that can serve as
a basis for timeout heuristics, when to close connections to misbehaving
servers and the means for a client to separate early close from
intentional end-of-document.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 484 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200731/f9fdbbf3/attachment-0001.sig>


More information about the Gemini mailing list