Cache duration and response body size proposals

[Gary Johnson]

bie <bie at 202x.moe> writes:

> I'm far from a TLS expert, so I might be completely wrong here, but
> can't the client rely on the server's TLS close_notify signal to decide if
> the download was interrupted? As far as I can tell, the entire point of
> close_notify is to guard against data truncation...?
>
> bie

That's right. Here's a summary of the issues and solutions proposed on
the mailing list over the past couple of weeks regarding various
content-size and content-hash response header proposals:

1. What about caching?

   This should either be performed by clients for links visited within a
   single session or not at all. If a client performs caching, it should
   provide some way to signal that you want to clear the current page
   from the cache and reload it.

2. How do I know if I got the entire response body?

   Your client will receive a TLS close_notify message when the server
   has finished sending the response. If you don't get one, the
   connection was broken. Retry your request or don't. It's up to you.

3. What if I'm impatient and am prone to canceling requests that take a
   long time?

   Outside of network latency issues or buggy servers, this should
   really only be happening when requesting large files. Content authors
   should consider including the file size for such files in their link
   descriptions, so the user will know generally how long they might
   have to wait.

   => /foo.mp3 foo.mp3 (14 MiB)

4. Okay, the link told me it was a big file, so I waited long enough for
   it to finish, and I know I got the whole file because I received a
   TLS close_notify message...but...how do I know I got all the intended
   bytes?

   If content validation is desirable, authors should provide a content
   hash in the link description or provide a separate link to a file
   containing the content hash (e.g., foo.mp3.md5 or foo.mp3.sha256):

   => /foo.mp3 foo.mp3 (14 MiB) SHA256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

5. Now can we add my proposal for sending content-size, content-hash,
   and cache-duration headers to Gemini responses?

   See 1-4 above.

That's all, folks!
  Gary

-- 
GPG Key ID: 7BC158ED
Use `gpg --search-keys lambdatronic' to find me
Protect yourself from surveillance: https://emailselfdefense.fsf.org
=======================================================================
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Why is HTML email a security nightmare? See https://useplaintext.email/

Please avoid sending me MS-Office attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html