For me personally, that brings the protocol a bit too close to the complexity of HTTP, but I'd be curious to hear what the use-cases for something like that would be...? When I used the word "permanent" it was just to draw a comparison to the 31 status code (REDIRECT - PERMANENT). The idea is just to let the client know that if it wants to cache the response for a session or however long it wants to... it's unlikely to cause any issues. bie On Fri, Nov 06, 2020 at 12:57:11PM +0530, Sudipto Mallick wrote: > Instead of "permanent" caching (what is permanent?) I am thinking > about using timestamps. > > So, for a requested resource, (if it is available) return a timestamp > which denotes when the resource was last changed. > > When requesting the resource again, send that timestamp with it and > the server checks if the cache is stale or not and responds > accordingly (either "resource is modified after $(old_timestamp) so > here is the new resource and it was modified on $(new_timestamp)" or > "the resource was not changed after $(timestamp)"). > > But the problem is, where does the timestamp goes in the request and response? > > > ~smlckz
---
Previous in thread (3 of 55): 🗣️ Björn Wärmedal (bjorn.warmedal (a) gmail.com)