It wouldn't just be about content integrity; it's also about caching. If the client has fetched a file before, and it hasn't changed since, there's no need to waste time and bandwidth fetching it again. On Fri, 30 Oct 2020 at 23:34, Nathan Galt <mailinglists at ngalt.com> wrote: > > > > On Oct 30, 2020, at 4:50 AM, Bj?rn W?rmedal <bjorn.warmedal at gmail.com> > wrote: > > > > There's been a lot of discussions about the lack of an end-of-message > indicator in the protocol. Clearly it's something that a lot of client and > server implementers are missing. > > > > A proposal that arose (I think acdw may have been the first to suggest > it; correct me if I'm wrong) was to include a "content-length: <nr of > bytes>" in the <META> of a status 20 response. It's a simple thing to add, > that doesn't extend the protocol into bloat. > > > > "But, ew0k! The <META> is for MIME types! That's not a MIME type!" > > > > Yes, this is true. Would that cause an issue? In that case calling it > "x-gemi-content-length" should resolve it, as the "x-" prefix is for > experimental types and any receiver that doesn't recognize it will ignore > it. I'm aware that it still doesn't convey info on the *type* of content, > and thereby doesn't belong among MIME type info, but it's a compromise I'm > willing to make. > > > > Are you? > > > > Cheers, > > BW/ew0k > > > If you?re worried whether the occasional big(gish) file transferred > correctly and don?t want to stand up an HTTP server, have you considered > publishing SHA-256 or -512 hashes, like one does for Linux-distribution > .iso files? -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201031/7c8c fad0/attachment.htm>
---
Previous in thread (14 of 48): 🗣️ Arav K. (nothien (a) uber.space)
Next in thread (16 of 48): 🗣️ Arav K. (nothien (a) uber.space)