Possible bug/design issue of Firefox on a page refresh regarding a cached asset under `Cache-Control: no-cache` with an etag
Crossposted from SO: What is the exact behavior of Firefox on a page refresh regarding a cached asset under `Cache-Control: no-cache`? Where can I find a document that specifies it?
On MDN regarding how `Cache-Control: no-cache` is supposed to work, I see that "the stored response MUST always go through validation with the origin server first before using it". Browsers use etags for this.
(Note: `Cache-Control: no-cache` actually allows caching; it isn't `no-store`; don't want that to confuse any answers.)
I author a web site that has a ordinary `<link>` to the main css file, with `Cache-Control: no-cache`, and sometimes Firefox makes the request as specified (an "etag request") which results in a 304 usually (or a 200 with the content if not).
But sometimes Firefox avoids such an "etag" request, especially when I press F5 to do an ordinary refresh. Chrome and Edge seem to always make these "etag requests", as I expect.
So that seems to go against MDN. **What is the intended behavior, and where is it documented?** And finally, is there anyway to coax Firefox into making the etag request on every F5 refresh?
Here are screenshots of the behavior: first request, and then after pressing F5 to refresh: https://i.stack.imgur.com/37zhu.png https://i.stack.imgur.com/ezpYl.png
Zmodyfikowany przez pszalapski w dniu
Wszystkie odpowiedzi (6)
Hi Patrick, what is the expiration date of the cached CSS file? Firefox 79 caches CSS files more tenaciously and you may not get a If-Modified-Since request for unexpired CSS file.
I added a note about it on the release notes -- https://wiki.developer.mozilla.org/docs/Mozilla/Firefox/Releases/79#CSS -- but it probably needs to be documented on the Cache-Control page, too.
Back in that time frame, I created a cache-prevention extension for developers who don't want to use the workarounds of disabling all caching or using Ctrl+F5:
https://addons.mozilla.org/firefox/addon/no-cache-no-store-for-css/
What does "expiration date" mean in this context--where would I find it? Since this is Cache-Control: no-cache, there is no max-age.
Does this aggressive caching not contradict the stern MUST spec I see on MDN: "the stored response MUST always go through validation with the origin server first before using it"?
Thanks for the extension note, but I am concerned that my users will see the old CSS, and thus improperly-styled pages, immediately after I deploy a new site with new CSS.
Zmodyfikowany przez pszalapski w dniu
I spent many hours researching this when Firefox 79 was released and I don't remember all the details now.
When I look at my test page, it seems that Firefox does honor no-cache for CSS files, at least with those headers:
https://www.jeffersonscher.com/csscache/
How about on yours?
Yes, your test page does not exhibit the behavior I see on my site--though I suspect it isn't testing the same scenario.
It appears your initial response on nocache.css does not send an etag with the file. I suspect this is the difference between our two scenarios. How do you make the server send the etag (which Firefox will I believe automatically use for subsequent requests, but perhaps improperly)? I noticed that your test page request for the nocache.css file has `Cache-Control: max-age=0`, but perhaps it should instead have `Cache-Control: no-cache` on it? (The response indeed has no-cache, but the request has max-age.)
Zmodyfikowany przez pszalapski w dniu
Would you be willing to add a row to your test page that makes a request that includes `Cache-Control: no-cache` on it?
I don't know how to prevent Firefox from including Cache-Control: max-age=0 in the Request headers when using the Reload button. However, if you click in the address bar and press Enter to load the page that way, Firefox does not send that header.