On 11/10/20 10:33 AM, Gary Johnson wrote: > 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 To further reduce the opportunity for undetected data corruption, clients could also keep an in-memory hash of the received data and compare this to a hash of the stored file. > 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 >
---
Previous in thread (14 of 16): 🗣️ Gary Johnson (lambdatronic (a) disroot.org)
Next in thread (16 of 16): 🗣️ Ali Fardan (raiz (a) stellarbound.space)