Comment by 🚀 jsreed5
Re: "Thought I want caching proxy to have ability access…"
Frankly, I don't think Gemini needs to implement a new status code for that. Caching is handled at the application level, not the network level, and many Gemini clients don't have caching at all. Those clients would have no use for a cache-specific status code.
If you want a code other than 20 to indicate loading from cache, you could (ab)use 30. Reading a cached copy of a page rather than loading a remote copy technically qualifies as a "redirection" from the remote copy to the local. By strict reading of the specification, the 30 status code does not require an explicit redirect URI, and the response body does not need to be empty. Clients could take advantage of that by sending a 30 code to themselves with no redirect URI and putting the cached document in the response body. This would strip the MIME type from the header, but clients could store that separately at cache time and retrieve it later.
Mar 31 · 5 weeks ago
1 Later Comment
🚀 lars_the_bear · Mar 31 at 12:44:
On the one hand, it seems reasonable for a client to wonder whether it's getting a cached result from a proxy or a live capsule.
On the other hand, AIUI Gemini has no way to communicate timestamps of documents, so the client will never know how old the document is anyway. And since that's the case, I have to wonder why the client would actually care whether it's getting something from a proxy's cache or not.
Original Post
Thought I want caching proxy to have ability access unavailable capsules from the local storage, so it seems that status 2* for cached resources is could be useful. By reading the docs, at this moment I don't know how to handle the document that recovered from browser cache / snap or external caching proxy.