Caching and status codes

[Philip Linde]

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/dab57087/attachment.sig>