On Fri, 6 Nov 2020 14:52:17 +0900
bie <bie at 202x.moe> wrote:
> Another suggestion made on irc was to do the opposite and create a "do
> not cache" 2x status code, but I'm not really sold on that. Caching
> introduces a lot of complexity even without a separate status code (how
> should query strings be handled, 1x responses, redirects?) and these
> issues don't go away if you add a "do not cache" code.
>
> Any thoughts...?
My own (end-user facing) client is a browser plugin and I inherit the
caching policy from it. Practically, this means for me that everything
is cached throughout the browsing session. An entry can be purged from
the cache by a "force reload" that the user can issue. I find this to
be a good all round policy for documents. For CGI I usually have to
issue a force reload. There could be three 2x codes:
20 (unspecified caching; unchanged from current spec)
21 ("permanent" caching)
22 (no caching)
A server that knows 21 and 22 can use them as appropriate on documents
that will never change and will always change respectively. A client
that doesn't understand them will still behave well because 2x is still
2x.
Then there's the question of whether this is something I've missed as a
user and implementer. Not really? I suppose being able to specify "no
caching" in particular is useful for CGI, but I spend most of my time
on Gemini reading documents that rarely change.
--
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/8722
9e49/attachment.sig>
---
Previous in thread (8 of 55): 🗣️ Philip Linde (linde.philip (a) gmail.com)
Next in thread (10 of 55): 🗣️ mbays (a) sdf.org (mbays (a) sdf.org)