Caching and status codes

[bie]

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