Hacker News Reader

Comment by bsimpson | Hacker News Reader

What about caching? If the HTML and the JS are both updated, but the browser receives the new version of one and the old version of another, this will break your page. (Since you'd now have to update the integrity attribute for every JS change, it means you run this risk every time you update your JS.)

To be fair, running a mismatched version of the JS could already break things if the changes are big enough, but for minor updates, the user often won't notice the difference. Now, these cases are hard failures. That's not necessarily a bad thing, but I wonder if there's a path here to tell the browser "you have an old version of the content; go get the new version."

CDNs and invalidations can be tricky, and it sounds like this could lead to things being broken more often if you're caught in the window where one piece updates before the other.

View on HN

This isn't a concern with our implementation because a hash of the asset bundle is also included in the URL. This is a pretty common cache-busting technique for static assets and lets you send more aggressive cache directives to the browser.

D'oh; that makes sense.

Maybe I should refrain from posting my gut reactions (or at least wait until I'm awake first). =)

No, it was a very good point. Not everyone adds hashes to filenames, and to me it seems that you're right in that weird caching can break pages that way.

If indeed this is the case, subresource integrity needs a big warning sign about that. For me, your comment was that warning sign, so please keep posting while you're not awake yet.

Why would it need a warning? If the HTML provides a new integrity="" hash, then any cached version obviously wouldn't pass. Subresource integrity makes it easier to determine if a cached file has expired. The file can be permanently cached for any HTML that requests the same hash value(s).

The browser could do something with this, but I believe it doesn't. Instead the algorithm is just:

1) Load the resource specified in src (from network or cache)

2) If there's an integrity attribute, verify its hash

SRI allows one to specify multiple hashes. In other words, to prevent this particular mismatch, one could include the hash of the new resource as well as the previous valid hash.

> What about caching? If the HTML and the JS are both updated, but the browser receives the new version of one and the old version of another, this will break your page.

Only if your page requires JavaScript to function and doesn't gracefully degrade. None of us would ever write that sort of page, would we?

None of us would ever indulge in soapbox politics, would we?

It would break anyway because pages are usually designed to degrade when JavaScript is disabled, not when the JavaScript fails to load or behaves in an unexpected way.

For example the <noscript> tag works that way.

You must give each new Javascript version a different filename (by including either the hash or a version number) and keep old Javascript version available forever or at least for a large enough timespan.

Reply on news.ycombinator.com