Reopening: Stream status code

[Paul Boyd]

Please don't. That would complicate generated responses. The server would
have to hold the response until the whole thing was rendered just to count
the number of bytes. It's a lot simpler to write the data as it's ready,
which also avoids (potentially large) temporary memory allocations.

Paul

On Fri, Jul 31, 2020, 6:34 AM Philip Linde <linde.philip at gmail.com> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200731/3bd836d8/attachment.htm>