Hello everyone! There's been some light discussion on the gemini irc channel about if and how clients should cache gemini responses, and I'd love to hear how people here think about the issue... Personally I feel like caching adds a ton of complexity, so the default behavior should be not to cache anything. There's no way to know if the response from a server is the product of a dynamic CGI script or a static file, and trying to guess at what's what will definitely introduce some weird behavior. Just to give some examples - on my personal site I have a script that returns a random jpeg, a guestbook and a simple gemlog, none of which should be cached! Now, I don't see the need for caching at all when it comes to gemini, but if it's something the gemini community wants or needs then I'd like to suggest a 2x status code that let's a client know that the response is unlikely to change and thus cacheable. This could even kind of match how the temporary/permanent redirect status codes are defined: 20 - SUCCESS 21 - "PERMANENT" SUCCESS (Feel free to cache this) This allows simple clients to keep doing what they're doing now (send a request, show the response) and allows more complex clients to play around with caching without breaking compatibility with what we already have. 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...? bie
---
Next in thread (2 of 55): 🗣️ Sudipto Mallick (smallick.dev (a) gmail.com)