> > Gemini has no support for caching This is referring to protocol-mandated caching, there's nothing saying a client can't cache at its discretion. It also implies that if your dynamic content doesn't work, then it's the client's fault, not yours nor the protocol's. > So I was a bit surprised when I was putting together some dynamic > content for my capsule and found that my client (amfora) was caching > things. I was able to get around it by using temporary redirects to > add cache busting query strings. Well behaved clients usually have some way to disable or get around the cache. For instance, Lagrange only caches forwards and backwards navigation, and any new links visited will not use the cache, even if you've already visited that page. Looking at the Amfora code, it seems like there's 3 limits to the cache[1]: number of pages, size in bytes, and number of seconds. This seems to be configurable[2],and it looks like it *should* (I may be misreading the code) hard reload the page when you refresh a tab[3]. Not that this is helpful for dynamic content, you can't expect your users to do an extra refresh every time, but helpful if you're viewing a dynamic page yourself. [1]: https://github.com/makeworld-the-better-one/amfora/blob/master/cache/page.go#L19-L3 [2]: https://github.com/makeworld-the-better-one/amfora/blob/master/config/ config.go#L199-L201 [3]: https://github.com/makeworld-the-better-one/amfora/blob/master/display /display.go#L591-L592 > > ...I only added it for cache-busting on lynx (otherwise you would > > always see the same result as the first time you loaded the page). This seems like lynx's fault. Caching a page permanently is not a good idea, even in webspace. > Is there some guarantee that a capsule writer has on what may _not_ be > cached, or is it entirely up to the client's discretion? If the > latter, is this something which could be clarified in the spec? My > impression from this ML was that caching is frowned upon (except for > perhaps navigating back and forth through your history), but this has > not been my experience (at least with amfora). There's no way to guarantee or request it, because pages assume they aren't cached. The consensus on caching should be that it should be only in special circumstances instead of the norm (for instance, caching forward/backward navigation only). I'd look to see if there's a way to disable caching on a per-site basis or at least temporarily disable it globally in Amfora, because having a cache that acts like that doesn't seem quite right. Absolute worst case, use a different client for dynamic content than you would use for static content. Just because I'm lazy I wouldn't go out of my way to implement cache busting, and instead just put a warning saying some clients may cache the page and cause it to not function properly. Especially when most clients don't cache, and the cache-busting would clog up forward/backward navigation on normal clients. ~nytpu -- Alex // nytpu alex at nytpu.com GPG Key: https://www.nytpu.com/files/pubkey.asc Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B https://useplaintext.email/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201222/caf4 c00c/attachment.sig>
---
Previous in thread (5 of 13): 🗣️ Philip Linde (linde.philip (a) gmail.com)
Next in thread (7 of 13): 🗣️ Stephen (stephen (a) drsudo.com)