7 ms·

What is the difference between an immutable resource and setting the resource to expire in 10 years? Many websites already do that, they change the URL each ti

What is the difference between an immutable resource and setting the resource to expire in 10 years? Many websites already do that, they change the URL each time the content changes.

kuschku 10y ago
Firefox won’t reload the resource, even if the page the resource is on is POSTed to. Use case: Logging into Facebook, previously browsers reloaded all resources.
- 64bittechie 10y ago
  You typically do a 302 redirect AFTER the POST authentication. This feels more of a publicity stunt more than anything. It might affect very few use-cases. Bulk of the requests on the web are GETs anyway.
  - niftich 10y ago
    I agree. Facebook redirects a successful login POST with a 302, which then results in a GET to '/'. This is an extremely common pattern. Once you're making GETs, 'fresh' resources can be served from cache without revalidation [1]. This is basically the whole point of the fresh vs. stale distinction. [1] https://tools.ietf.org/html/rfc7234#section-1 https://tools.ietf.org/html/rfc7234#section-1
- nimrody 10y ago
  Why would the browser need to reload all resources after a POST request? 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.
jjoe 10y ago
The difference is that in the case of immutable the browser does not send a 304 conditional.
- duskwuff 10y ago
  Really? The article implies that the whole point of Immutable is that the browser won't revalidate contents. (Also, "304" is an HTTP response code -- "Not Modified" -- not something the browser sends.)
  - jjoe 10y ago
    Meant to say that there's no conditional with immutable. Corrected, thanks.
    - duskwuff 10y ago
      I still don't think that's accurate. My experience is that a future Expires date -- even relatively near-future -- is sufficient to prevent an If-Modified-Since request. (Which is what I think you mean by "304 request".)
      - jjoe 10y ago
        It's up to the client to decide based on Last-Modified (if previously sent by the server) and its own implementation. But I guess browsers are going to be a tad bit aggressive especially if Last-Modified is absent. Hence the overly aggressive 304s.
      - bzbarsky 10y ago
        For normal loads, yes. 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.
        duskwuff 10y ago
        Aha. The forced If-Modified-Since on reload is the piece I was missing. Thanks.
Klathmon 10y ago
I'm not sure if this is in-use anywhere, but it may lead to better "cache eviction" policies. Saying something is immutable has different implications than saying "I want it cached for 10 years". 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.
- jrochkind1 10y ago
  I'd imagine 'immutable' but not recently used things will still be evicted from the cache at some points, when space is needed. There's no reason for them not to be, is there? 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?
- jonknee 10y ago
  > Saying something is immutable has different implications than saying "I want it cached for 10 years". 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.
  - Klathmon 10y ago
    Oh definitely, I meant more in the sense of being able to evict things more "intelligently". 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.
paulddraper 10y ago
The reality of most browsers is that they ignore the cache time in many cases, like refreshing, in order to work with broken pages. In a perfect world, we'd just be able to max-age and immutable would be redundant.
- magila 10y ago
  Which raises the question: How long until browsers start ignoring the immutable header to work around broken pages?
tyingq 10y ago
They say the difference goes back to this observation[1] from Facebook: "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/msg25463.html https://www.ietf.org/mail-archive/web/httpbisa/current/msg25...
- niftich 10y ago
  They could just be seeing 10%-20% of the people doing a Ctrl+F5 'force refresh' -- after all, they're speculating, and have no real data on whether browser or user behavior is responsible for the numbers they're seeing.
  - Tenoke 10y ago
    You think they didn't test their assumption?
    - niftich 10y ago
      I think they did, but there's not enough information available to reliably distinguish 'normal' reloads from 'force-reloads', unless they ran onKeyDown javascript and correlated the events after the fact. 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#c50 https://bugs.chromium.org/p/chromium/issues/detail?id=505048... [2] https://developer.mozilla.org/en-US/docs/Web/API/Navigation_timing_API https://developer.mozilla.org/en-US/docs/Web/API/Navigation_...
  - tyingq 10y ago
    Firefox themselves appear to have tested and confirmed that regular F5/Refresh (not Ctrl+F5) causes revalidation: http://bitsup.blogspot.de/2016/05/cache-control-immutable.html http://bitsup.blogspot.de/2016/05/cache-control-immutable.ht...
mbell 10y ago
The 'reload' action in browsers has a different meaning than most people expect and does not do the same thing as highlighting the url and hitting enter, or pasting the url into a new tab. 'reload' forces all assets to be re-validated, regardless of the freshness of the cache. The `immutable` header allows browsers to skip this revalidation.
deleted 10y ago
[deleted]

What is the difference between an immutable resource and setting the resource to expire in 10 years? Many websites already do that, they change the URL each time the content changes.

kuschku 10y ago

Firefox won’t reload the resource, even if the page the resource is on is POSTed to. Use case: Logging into Facebook, previously browsers reloaded all resources.

64bittechie 10y ago
You typically do a 302 redirect AFTER the POST authentication. This feels more of a publicity stunt more than anything. It might affect very few use-cases. Bulk of the requests on the web are GETs anyway.
- niftich 10y ago
  I agree. Facebook redirects a successful login POST with a 302, which then results in a GET to '/'. This is an extremely common pattern. Once you're making GETs, 'fresh' resources can be served from cache without revalidation [1]. This is basically the whole point of the fresh vs. stale distinction. [1] https://tools.ietf.org/html/rfc7234#section-1 https://tools.ietf.org/html/rfc7234#section-1
nimrody 10y ago
Why would the browser need to reload all resources after a POST request? 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.

jjoe 10y ago

The difference is that in the case of immutable the browser does not send a 304 conditional.

duskwuff 10y ago
Really? The article implies that the whole point of Immutable is that the browser won't revalidate contents. (Also, "304" is an HTTP response code -- "Not Modified" -- not something the browser sends.)
- jjoe 10y ago
  Meant to say that there's no conditional with immutable. Corrected, thanks.
  - duskwuff 10y ago
    I still don't think that's accurate. My experience is that a future Expires date -- even relatively near-future -- is sufficient to prevent an If-Modified-Since request. (Which is what I think you mean by "304 request".)
    - jjoe 10y ago
      It's up to the client to decide based on Last-Modified (if previously sent by the server) and its own implementation. But I guess browsers are going to be a tad bit aggressive especially if Last-Modified is absent. Hence the overly aggressive 304s.
    - bzbarsky 10y ago
      For normal loads, yes. 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.
      - duskwuff 10y ago
        Aha. The forced If-Modified-Since on reload is the piece I was missing. Thanks.

Klathmon 10y ago

I'm not sure if this is in-use anywhere, but it may lead to better "cache eviction" policies. Saying something is immutable has different implications than saying "I want it cached for 10 years". 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.

jrochkind1 10y ago
I'd imagine 'immutable' but not recently used things will still be evicted from the cache at some points, when space is needed. There's no reason for them not to be, is there? 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?
jonknee 10y ago
> Saying something is immutable has different implications than saying "I want it cached for 10 years". 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.
- Klathmon 10y ago
  Oh definitely, I meant more in the sense of being able to evict things more "intelligently". 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.

paulddraper 10y ago

The reality of most browsers is that they ignore the cache time in many cases, like refreshing, in order to work with broken pages. In a perfect world, we'd just be able to max-age and immutable would be redundant.

magila 10y ago
Which raises the question: How long until browsers start ignoring the immutable header to work around broken pages?

tyingq 10y ago

They say the difference goes back to this observation[1] from Facebook: "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/msg25463.html https://www.ietf.org/mail-archive/web/httpbisa/current/msg25...

niftich 10y ago
They could just be seeing 10%-20% of the people doing a Ctrl+F5 'force refresh' -- after all, they're speculating, and have no real data on whether browser or user behavior is responsible for the numbers they're seeing.
- Tenoke 10y ago
  You think they didn't test their assumption?
  - niftich 10y ago
    I think they did, but there's not enough information available to reliably distinguish 'normal' reloads from 'force-reloads', unless they ran onKeyDown javascript and correlated the events after the fact. 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#c50 https://bugs.chromium.org/p/chromium/issues/detail?id=505048... [2] https://developer.mozilla.org/en-US/docs/Web/API/Navigation_timing_API https://developer.mozilla.org/en-US/docs/Web/API/Navigation_...
- tyingq 10y ago
  Firefox themselves appear to have tested and confirmed that regular F5/Refresh (not Ctrl+F5) causes revalidation: http://bitsup.blogspot.de/2016/05/cache-control-immutable.html http://bitsup.blogspot.de/2016/05/cache-control-immutable.ht...

mbell 10y ago

The 'reload' action in browsers has a different meaning than most people expect and does not do the same thing as highlighting the url and hitting enter, or pasting the url into a new tab. 'reload' forces all assets to be re-validated, regardless of the freshness of the cache. The `immutable` header allows browsers to skip this revalidation.

deleted 10y ago

[deleted]