💾 Archived View for rawtext.club › ~sloum › geminilist › 003080.gmi captured on 2020-11-07 at 03:20:40. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
bie bie at 202x.moe
Fri Nov 6 07:44:00 GMT 2020
- - - - - - - - - - - - - - - - - - -
For me personally, that brings the protocol a bit too close to thecomplexity of HTTP, but I'd be curious to hear what the use-cases forsomething like that would be...?
When I used the word "permanent" it was just to draw a comparison to the31 status code (REDIRECT - PERMANENT). The idea is just to let theclient know that if it wants to cache the response for a session orhowever 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