💾 Archived View for rawtext.club › ~sloum › geminilist › 002362.gmi captured on 2020-09-24 at 03:10:20. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Paul Boyd boyd.paul2 at gmail.com
Fri Jul 31 12:01:10 BST 2020
- - - - - - - - - - - - - - - - - - -
Please don't. That would complicate generated responses. The server wouldhave to hold the response until the whole thing was rendered just to countthe 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>