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.

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.

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.

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.

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.

Yes, and it also had to work (long ago) with poorly-written, non-standards-compliant HTTP proxies.