5 ms·

I still don't really get what's so special about "cache-control: immutable". Isn't it the same as setting the cache expiration date to something like in a year

I still don't really get what's so special about "cache-control: immutable". Isn't it the same as setting the cache expiration date to something like in a year or two? Why is a special property needed for this?

deleted 10y ago
[deleted]
evmar 10y ago
When you hit the reload button, the browsers would still revalidate resources with long expiration dates. The fixes in the Facebook post are that Chrome changed to no longer do this on any subresource, and Firefox changed to no longer do this on cache-control: immutable resources.
- lucb1e 10y ago
  I thought this was possible... that explains my frustration with "why won't the damn thing not revalidate" when I last tried it (I think that was a few years ago by now). Weird though, it seems so obvious and I thought something like no-revalidate existed. I guess I'm confusing no-cache and must-revalidate.
petrosagg 10y ago
The problem is that when a user refreshes the page using the reload button the browser will revalidate even cached resources. This results in a lot of requests that get carry the `If-Modified-Since` header and 304 responses. Cache-Control: immutable avoids this revalidation altogether since it's guaranteed that the source won't ever change.
klodolph 10y ago
The problem is that browsers didn't do the right thing, and now they can't do the right thing because web developers relied on actual browser behavior rather than idealized spec-compliant behavior. If you've heard that story before, it's because a dozen other minor warts (especially regarding HTTP headers) appeared for the exact same reason.
- Groxx 10y ago
  Well... kinda. I'd say this is the result of a mismatch between "refresh everything, anything could have changed" and what most people actually want when refreshing, which is "check for new content". "cache-control: immutable" at least lets servers declare a contract that pushes those two closer towards each other, and it also works perfectly for those cache-busting resource-version-params, which browsers haven't been able to trust. Which is probably why Chrome had that POST-invalidation thing - there are a lot of flawed cache headers out there, and users don't care that you're following the spec when things break.
  - klodolph 10y ago
    Yes, and it also had to work (long ago) with poorly-written, non-standards-compliant HTTP proxies.

deleted 10y ago

[deleted]

evmar 10y ago

When you hit the reload button, the browsers would still revalidate resources with long expiration dates. The fixes in the Facebook post are that Chrome changed to no longer do this on any subresource, and Firefox changed to no longer do this on cache-control: immutable resources.

lucb1e 10y ago
I thought this was possible... that explains my frustration with "why won't the damn thing not revalidate" when I last tried it (I think that was a few years ago by now). Weird though, it seems so obvious and I thought something like no-revalidate existed. I guess I'm confusing no-cache and must-revalidate.

petrosagg 10y ago

The problem is that when a user refreshes the page using the reload button the browser will revalidate even cached resources. This results in a lot of requests that get carry the `If-Modified-Since` header and 304 responses. Cache-Control: immutable avoids this revalidation altogether since it's guaranteed that the source won't ever change.

klodolph 10y ago

The problem is that browsers didn't do the right thing, and now they can't do the right thing because web developers relied on actual browser behavior rather than idealized spec-compliant behavior. If you've heard that story before, it's because a dozen other minor warts (especially regarding HTTP headers) appeared for the exact same reason.

Groxx 10y ago
Well... kinda. I'd say this is the result of a mismatch between "refresh everything, anything could have changed" and what most people actually want when refreshing, which is "check for new content". "cache-control: immutable" at least lets servers declare a contract that pushes those two closer towards each other, and it also works perfectly for those cache-busting resource-version-params, which browsers haven't been able to trust. Which is probably why Chrome had that POST-invalidation thing - there are a lot of flawed cache headers out there, and users don't care that you're following the spec when things break.
- klodolph 10y ago
  Yes, and it also had to work (long ago) with poorly-written, non-standards-compliant HTTP proxies.