fetch
fetch copied to clipboard
whatwg
Cache mode: fromCache
We want to introduce fromCache member on Response objects. However, this in part depends on how we tackle #38 and also #39 of course. If a Response is partially formed from a cached entry, should it say "partial"?
Given that the use case for this is https://github.com/slightlyoff/ServiceWorker/issues/412#issuecomment-57635369 which is somewhat obscure, I'm not planning on addressing this for now.
I don't think that the linked use case is all that valid regarding this feature. I'd say this https://github.com/whatwg/fetch/issues/39#issuecomment-140908410 is much more applicable.
Determining whether a resource comes from the cache is an important part of the bandwidth estimation that must be handled when serving adaptive bitrate video content. The fromCache attribute would enable more accurate estimation. Currently, this can only be approximated using response timing information.
Yes, but from that issue we also know that only-if-cached is not acceptable for security reasons and this would expose exactly that. And if we limit this to same-origin it would not at all be interesting for video content.
Perhaps it's best to remove the "cache state" concept from the specification for now until we find a way to address these issues.
Hmm... Given that the security concerns would be largely circumvented if the server allows the client to sends If-Modified-Since, If-None-Match, etc, it might be possible to use this to enable this feature for such CORS requests?
Of course this would require a CORS pre-flight request to discover, which means that the fromCache attribute would require a special mode / flag to enable on a request.
FWIW - I think this is a bit different than only-if-cached. The problem there is that it makes it possible to probe the cache without any corresponding traffic being emitted to the server, making it a passive attack.
Exposing fromCache doesn't do that; if someone tries to use it for probing, it will still emit traffic.
What it does do is slightly improve confidence as opposed to cache timing attacks (but they're pretty conclusive anyway, AIUI).
Maybe, within server respons headers Cache-Control: stale-*, to solve this problem?
RFC5861
https://tools.ietf.org/rfc/rfc5861.txt
As Resource Timing exposes some this information, it's reasonable to consider exposing it directly on Response objects again for convenience.
A complementary API to this might be a more explicit opt-in for surfacing 304 responses to the caller, saving the browser from obtaining the full response from the cache. (This is already possible if the caller sets certain headers themselves, but perhaps that ought to have a more abstract entry point as well.)