Cache duration and response body size proposals

[Philip Linde]

On Tue, 10 Nov 2020 15:36:01 +0000
"Robert \"khuxkm\" Miles" <khuxkm at tilde.team> wrote:

> But then this goes back to the whole discussion we had about caching: sure, the overhead of a TLS connection is low, but it's not zero. If I know for a fact that the response I got has as many bytes as I was told I had, then even in the absence of a close_notify, I know for a fact I have the whole response and can be sure in that.

Sure, but as an argument for inclusion this is not compelling enough to
warrant the proposed change IMO. Knowing for sure that you don't know
whether you have received a full response is almost as good as knowing
for sure that you have in this context. It's only in the unlikely edge
case that a server might want to send close_notify but the client fails
to receive it (and only it) that it's useful to save an additional
request, and considering the hacky piggybacking on MIME parameters the
proposal entails (that RFC 2045 in the most forgiving interpretation at
least advises against), it's a small win.

A more compelling argument IMO is that knowing the expected size in
advance, you can support progress bars and time estimates. Another
compelling argument might be that a lot of servers apparently ignore
the fact that they *have to* close_notify, which also seems like par for
the course for web servers.

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