Should the cache control default mode match how the page is loaded?

[ehsan]

@upsuper suggested something interesting to me today. Right now when the a page is reloaded, the resources during the page load are requested with no-cache, and if the user shift-reloads, the resources are requested with no-store. However this only affects the fetches happening when the document is being loaded, and it doesn't for example affect the resources fetched using the fetch API. The idea is to remember the cache mode used in the initial load of the document and use that as the default cache mode for fetch.

@annevk, curious to know what you think.

[jakearchibald]

Agreed, we dropped isReload in service worker in favour of this.

[annevk]

That would mean there is some cache mode on a global too... Is it on the fetch group (load group in Gecko)? Or simply on the document/global?

[upsuper]

The issue is that, with the current default value, other than clearing the whole cache, user can never force updating resources fetched via fetch().

Also without a full implementation of cache mode (no browser is currently shipping cache mode support as far as I know), authors do not have many choices as well. They might need to either configure the server to explicitly disable caching via sending some header in responses, or append some kind of revision string to the url.

The combination of these issues leads to a poor development experience to me.

[annevk]

To be clear, I'm not opposed to fixing this, I'm just trying to figure out the architecture.

[wanderview]

What does xhr do today when used from a refreshed document? How about dynamically created img and script elements?

I personally don't like adding this global state since the spec already provides RequestCache for bypassing HTTP cache.

Cache mode is implemented in Firefox 48.

[ehsan]

I personally don't like adding this global state since the spec already provides RequestCache for bypassing HTTP cache.

I think the reason for this proposal is giving the users control over what behavior fetch() has (as opposed to the developer), similar to what browsers currently are doing for the top-level resource and its subresources.

[ehsan]

Note that Facebook is proposing changing what the reload button does by making it only validate the main page but not subresources, and apparently Chrome is on board. If that behavior change gets adopted by browsers, that will change the landscape around this issue. See https://bugzilla.mozilla.org/show_bug.cgi?id=1267474 and https://bugs.chromium.org/p/chromium/issues/detail?id=600636.

[wanderview]

I think the reason for this proposal is giving the users control over what behavior fetch() has (as opposed to the developer), similar to what browsers currently are doing for the top-level resource and its subresources.

We already provide maximum flexibility for devs by doing fetch(url, { cache: 'no-store' }) or whatever cache policy they want. I don't know why adding a magic global default would improve this flexibility. I think it would just confuse everyone.

I think it would be less breaking and less surprising if we exposed how the document was loaded and then let script decide what they want to do. Something like document.loadedRequest. Then they could do fetch(url, { cache: document.loadedRequest.cache }) to inherit the http cache policy used to request the document.

Note that Facebook is proposing changing what the reload button does by making it only validate the main page but not subresources, and apparently Chrome is on board. If that behavior change gets adopted by browsers, that will change the landscape around this issue.

Well, I have my doubts as you can see from my comments in that bug.

[upsuper]

I guess Chrome's proposal around reload probably works, and even with that, users still have hard-reload to bypass all cache and reload everything. But resources get via fetch() would not be revalidated even in that case.

[toyoshim]

Let me check if I understand this thread correctly.

The original proposal: If a user specify "default" for Request.cache, browser want to modify it to relevant cache mode before showing it to SW on fetch event as it does for requests for page loading.

This will help users to support reload or other navigations like back/forward correctly without any extra efforts.

On the other hand, users can manually implement their own reload or navigation strategy by referring window.performance.navigation.type to decide the request cache mode.

I'm not sure changing "default" behavior is a good idea. Adding "auto" would be another choice to have such options for users. Otherwise, users could not specify to enforce using the mode to follow the cache protocol.

FYI, basically in Chrome, created img or script resources would use per-frame cache mode until onload event is fired. Resources created after the event just follows the cache protocol. But this is NOT true for XHR. FrameFetchContext manages such cache mode decisions in Chrome.

[annevk]

See also https://github.com/whatwg/html/issues/5222 and https://github.com/whatwg/html/issues/6718.