On Fri, 6 Nov 2020 08:43:39 +0100 Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote: > Adding a response code like that is counterproductive, I believe, as > there's really no way for a server to determine what sort of file or > data is unlikely to change, and there's no way for a client to > determine what a flag of "unlikely to change" means. Does it mean it > won't change in the next hour? The next month? Why does the server need to determine this? It should be up to the server admin to determine it. If I have some file I want to serve that I anticipate will never change, I configure the server to respond to reqeusts for it with code 21. The client can take this to mean a week, a day or forever depending on how sure the user wants to be that the information is current. The client could override this behavior by allowing the user to force a cache entry to be purged. > As mentioned in previous discussions on caching and checksums, there's > not really room in the protocol specification for the needed > information unless you start misusing MIME type info. This doesn't at all address the suggested solution, which there *is* room for in the protocol. No need to misuse MIME type info. No need for breaking changes to the specification. As suggested, this is entirely backwards-compatible, older clients and servers are entirely forwards-compatible and the change to the spec would be entirely additive. -- 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/20201106/dab5 7087/attachment.sig>
---
Previous in thread (7 of 55): 🗣️ Philip Linde (linde.philip (a) gmail.com)
Next in thread (9 of 55): 🗣️ Philip Linde (linde.philip (a) gmail.com)