search

whatwg / fetch

Fetch Standard
https://fetch.spec.whatwg.org/
Other
2.11k stars 330 forks source link

Cache mode: fromCache #40

Open annevk opened 9 years ago

annevk commented 9 years ago

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"?

annevk commented 8 years ago

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.

kanongil commented 8 years ago

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.

annevk commented 8 years ago

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.

annevk commented 8 years ago

Perhaps it's best to remove the "cache state" concept from the specification for now until we find a way to address these issues.

kanongil commented 8 years ago

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.

mnot commented 8 years ago

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).

ParkFramework commented 8 years ago

Maybe, within server respons headers Cache-Control: stale-*, to solve this problem? RFC5861 https://tools.ietf.org/rfc/rfc5861.txt

annevk commented 8 years ago

@mikewest what do you think with regards to @mnot analysis?

annevk commented 3 years ago

As Resource Timing exposes some this information, it's reasonable to consider exposing it directly on Response objects again for convenience.

annevk commented 2 years ago

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.)