4 ms·

More technical details are available in the Facebook post linked at the bottom of the article. https://code.facebook.com/posts/557147474482256 https://code.face

More technical details are available in the Facebook post linked at the bottom of the article. https://code.facebook.com/posts/557147474482256 https://code.facebook.com/posts/557147474482256 > we found that Chrome would revalidate all resources on pages that were loaded from making a POST request. The Chrome team told us the rationale for this was that POST requests tend to be pages that make a change — like making a purchase or sending an email — and that the user would want to have the most up-to-date page. However, sites like Facebook use POST requests as part of our login process. Every time a user logged in to Facebook the browser ignored its cache and revalidated all the previously downloaded resources. We worked with Chrome product managers and engineers and determined that this behavior was unique to Chrome and unnecessary. After fixing this, Chrome went from having 63% of its requests being conditional to 24% of them being conditional. And later on, discussing immutable long-cached resources: > There was some debate about what to do, and we proposed a compromise where resources with a long max-age would never get revalidated, but that for resources with a shorter max-age the old behavior would apply. The Chrome team thought about this and decided to apply the change for all cached resources, not just the long-lived ones. You can read more about their process here [the parent article]. Because of Chrome's blanket approach, all developers and sites are able to see improvement without making any changes themselves. They say Firefox resolved not to implement it this way, instead adding a new cache-control header, "immutable." https://hacks.mozilla.org/2017/01/using-immutable-caching-to-speed-up-the-web/ https://hacks.mozilla.org/2017/01/using-immutable-caching-to... So, uh, this means that Chrome and Firefox now have very different caching behavior, by design. :-( I must say that I prefer Firefox's approach, or even FB's approach where long-lived cache results are handled differently. Refresh's revalidation behavior provides a valuable safety net to ensure that users know how to get a page "back to normal." Regardless, I wish the Chrome and Firefox team would come to agreement on a proposal, rather than each doing their own thing. That's bad for the web.

joekrill 10y ago
Very unfortunate that the Chromium team decided to go this route. At least the Firefox approach leaves it in the hands of whoever is serving the content. Chromium now just makes an assumption, and completely changes existing behavior.
benjaminjackman 10y ago
I agree that immutable seems like a better solution. But it still puts a little too much trust in the urls not breaking and puts an unnecessary onus solving a solved problem. Immutable resources should be referred to by some straightforward variaton of a hash of the immutable bytes that form their content. Its similar to how git works for example. [1] So what does this look like in practice? rather than serve a your css as <link rel="stylesheet" type="text/css" "ref="https://example.com/styles/site.css"/> you'd instead use something like[2]: <link rel="stylesheet" type="text/css" "ref="sha256:abc123..."/> And all the resources could be verified for integrity after being downloaded and trivially changed thereafter. For privacy concerns, the url provides the additional feature of sandboxing the content via the origin access controls. As a step 2 addition the urn could still contain the current url style as an optional suffixed parameter, which if provided the browser would use to sandbox that particular hash to that site as a provider of it. Referring to that hash from a site that has not previously provided the data would fail, unless the site is able to either prove that has the data by resending it, or rehashing it some way. 1: I don't mean to be pedantic but a lot of people don't understand that you can take any number of bytes, compute a 256 or 512 bit cryptographic hash for it, and be guaranteed of a longer than the lifetime of the universe level small chance of ever finding any other bytes that produce the same 256 or 512 bit number, even when trying as hard as you can with all the resources you can muster. 2: There are several different ways to do the addressing for the content (magnet uris, IPFS univeral hashes etc). The browser vendors ought to pick one and move on.
- benmaurer 10y ago
  We discussed this approach -- one difficulty with it is that the website often doesn't know the hash of the resource. For example, imagine a server that takes urls of the from images.fbcdn.net/abc124.jpg/200x200 and dynamically resizes the image to 200x200 px. It it is impossible to know what the hash of this resource will be without calculating it beforehand. The subresource integrity spec supports cases where the developer is able to calculate the hash beforehand
  - benjaminjackman 10y ago
    I hadn't considered dynamic urls as the dominant use case. But I can certainly see the importance in handling them as well. To me that feel like a function memoization problem (e.g. this example was a function of 2 parameters, height and width). For that case passing along cache-control: immutable, integrity: sha-abc123 headers in the response feels like the best current solution. Though it would be nice to somehow have the url self-descriptively assert its purity. Something to the effect of saying `I don't have the content-hash for this now but whatever i return is going to be immutable`, rather than having to muck around in the web-server protocol layer to assert that fact via cache-control: immutable. I think fundamentally the metadata on whether a particular url is immutable/pure or not, should be self evident, rather than buried in as an implementation detail in the response's http header.
nachtigall 10y ago
> I must say that I prefer Firefox's approach, or even FB's approach where long-lived cache results are handled differently Discussion of the Firefox approach: https://news.ycombinator.com/item?id=13493407 https://news.ycombinator.com/item?id=13493407

joekrill 10y ago

Very unfortunate that the Chromium team decided to go this route. At least the Firefox approach leaves it in the hands of whoever is serving the content. Chromium now just makes an assumption, and completely changes existing behavior.

benjaminjackman 10y ago

I agree that immutable seems like a better solution. But it still puts a little too much trust in the urls not breaking and puts an unnecessary onus solving a solved problem. Immutable resources should be referred to by some straightforward variaton of a hash of the immutable bytes that form their content. Its similar to how git works for example. [1] So what does this look like in practice? rather than serve a your css as <link rel="stylesheet" type="text/css" "ref="https://example.com/styles/site.css"/> you'd instead use something like[2]: <link rel="stylesheet" type="text/css" "ref="sha256:abc123..."/> And all the resources could be verified for integrity after being downloaded and trivially changed thereafter. For privacy concerns, the url provides the additional feature of sandboxing the content via the origin access controls. As a step 2 addition the urn could still contain the current url style as an optional suffixed parameter, which if provided the browser would use to sandbox that particular hash to that site as a provider of it. Referring to that hash from a site that has not previously provided the data would fail, unless the site is able to either prove that has the data by resending it, or rehashing it some way. 1: I don't mean to be pedantic but a lot of people don't understand that you can take any number of bytes, compute a 256 or 512 bit cryptographic hash for it, and be guaranteed of a longer than the lifetime of the universe level small chance of ever finding any other bytes that produce the same 256 or 512 bit number, even when trying as hard as you can with all the resources you can muster. 2: There are several different ways to do the addressing for the content (magnet uris, IPFS univeral hashes etc). The browser vendors ought to pick one and move on.

benmaurer 10y ago
We discussed this approach -- one difficulty with it is that the website often doesn't know the hash of the resource. For example, imagine a server that takes urls of the from images.fbcdn.net/abc124.jpg/200x200 and dynamically resizes the image to 200x200 px. It it is impossible to know what the hash of this resource will be without calculating it beforehand. The subresource integrity spec supports cases where the developer is able to calculate the hash beforehand
- benjaminjackman 10y ago
  I hadn't considered dynamic urls as the dominant use case. But I can certainly see the importance in handling them as well. To me that feel like a function memoization problem (e.g. this example was a function of 2 parameters, height and width). For that case passing along cache-control: immutable, integrity: sha-abc123 headers in the response feels like the best current solution. Though it would be nice to somehow have the url self-descriptively assert its purity. Something to the effect of saying `I don't have the content-hash for this now but whatever i return is going to be immutable`, rather than having to muck around in the web-server protocol layer to assert that fact via cache-control: immutable. I think fundamentally the metadata on whether a particular url is immutable/pure or not, should be self evident, rather than buried in as an implementation detail in the response's http header.

nachtigall 10y ago

> I must say that I prefer Firefox's approach, or even FB's approach where long-lived cache results are handled differently Discussion of the Firefox approach: https://news.ycombinator.com/item?id=13493407 https://news.ycombinator.com/item?id=13493407