Many websites already do that, they change the URL each time the content changes.
Many websites already do that, they change the URL each time the content changes.
The former would allow a browser to apply some heuristics and say for example evict something from the cache when it hasn't been referenced on a page for the last 5 times you went there (the assumption being that it was changed and the new resource is taking over in it's place).
That can lead to things being held in the cache for longer without having to use a straight "oldest evicted first" kind of method which can lead to thrashing if the cache size is too small or some resources are too big.
A browser can already apply different eviction policies to things with very long `expires`, I don't know if any do.
I'm having trouble seeing what this adds practically, too. I guess it's more of a clear semantic intent to say 'immutable' when you need that, instead of 'expires a long time from now'. Practically though?
Only if you have a system that you keep for more than 10 years. If a browser dumps stuff that it was told it can keep for a decade that means it can also dump stuff that it was told will never change. If the cache is full of things that are immutable something still has to go.
If stuff needs to go, it needs to go. It's going to happen. But if you have to choose between a file which was told to be cached for 10 years, and one which was labeled "immutable" but hasn't been referenced on the page it was previously for the last 10 loads, it might be a better choice to evict the immutable one.
Generally browser caches are "last used first out". So if you start stuffing the cache with a bunch of stuff you can already push the oldest out. And if you fill the whole thing you'll remove everything else.
It was actually quite a problem on mobile browsers for a while. IIRC iOS had something like a 10MB cache for the longest time. A few heavy websites and your whole cache would cycle through. Android had a 5MB cache at one point as well! A shitty news site can already fill that single handedly.
But my idea here (which I gave about 5 minutes of thought...) Was that immutable content would be evicted before the "10 year" stuff. The idea being that if something replaced an immutable "thing" it could be evicted much sooner.
I'm not sure if it would really help at all, just kind of throwing out some ideas.
"we've noticed that despite our nearly infinite expiration dates we see 10-20% of requests (depending on browser) for static resource being conditional revalidation. We believe this happens because UAs perform revalidation of requests if a user refreshes the page"
It sounds like immutable is being introduced so that Firefox can leave the current behavior in place, and only instantiate the new behavior for "immutable" resources.
This seems different than the chrome approach, where they plan on changing the behavior for all "unexpired" resources.
[1]https://www.ietf.org/mail-archive/web/httpbisa/current/msg25...
A comment from Facebook [1] on the Chrome bug says they started logging 'window.performance.navigation.type', which distinguishes between [2] normal navigation, reload, history traversal (back/forward), and undefined.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=505048... [2] https://developer.mozilla.org/en-US/docs/Web/API/Navigation_...
(Also, "304" is an HTTP response code -- "Not Modified" -- not something the browser sends.)
The problem people are trying to solve here is that users hit the relaod button. A lot. And if you hit the reload button, that will send If-Modified-Since for everything on the page, no matter what Expires says, because the user intent is to ignore Expires headers.
That's what the immutable thing is about: indicating that even in the reload scenario the Expires is authoritative and no If-Modified-Since request should be sent.
Use case: Logging into Facebook, previously browsers reloaded all resources.
Presumably, only the main (HTML) page should be refreshed and other linked items (CSS/JS/media) with high max-age (and no 'must-revalidate' cache control header) should use the previously cached content.
In a perfect world, we'd just be able to max-age and immutable would be redundant.