Re: [slightlyoff/ServiceWorker] should FetchEvent.request.cache reflect non-fetch browser cache controls? (#875)

> Refreshing the document triggers fetches to:
N - cache mode: "default" or "no-cache"? (currently "default"; no step overrides the value)
R - cache mode: "no-store" or "no-cache"? (currently "no-store"; no step overrides the value)
Intercepted by SW: yes - the cache mode values don't matter
When they're bypassed to the network stack: we may expect "no-cache" for both N and R

I would expect R to be `no-store` in this case.  This is what we do in gecko.

> Force refreshing the document triggers fetches to:
N - cache mode: "default" or "reload"? (currently "default"; no step overrides the value)
R - cache mode: "no-store" or "reload"? (currently "no-store"; no step overrides the value)
Intercepted by SW: no
When they get to the network stack: we may expect "reload" for both N and R

In gecko we report `no-store` for both N and R here.

Personally I think `default` should mean "follow cache-control headers".

I'm not sure where it is spec'd, but I think refresh and hard refresh should do something like:

* When a page is refreshed set request.cache to `no-cache` if request.cache is currently `default`.
* When a page is hard refreshed set request.cache to `no-store` in request.cache is currently `default`.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/875#issuecomment-239475317

Received on Friday, 12 August 2016 15:20:00 UTC