💾 Archived View for rawtext.club › ~sloum › geminilist › 003084.gmi captured on 2020-11-07 at 03:20:50. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Philip Linde linde.philip at gmail.com
Fri Nov 6 10:24:00 GMT 2020
- - - - - - - - - - - - - - - - - - -
On Fri, 6 Nov 2020 08:43:39 +0100Bjö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 theserver admin to determine it. If I have some file I want to serve thatI anticipate will never change, I configure the server to respond toreqeusts 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 theinformation is current. The client could override this behavior byallowing 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 forbreaking changes to the specification. As suggested, this is entirelybackwards-compatible, older clients and servers are entirelyforwards-compatible and the change to the spec would be entirelyadditive.
-- Philip-------------- next part --------------A non-text attachment was scrubbed...Name: not availableType: application/pgp-signatureSize: 488 bytesDesc: not availableURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201106/dab57087/attachment.sig>