Re:Subresource Integrity
by mastahyeti on Friday September 18, 2015 @02:51PM
(#10241293)
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?
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.
Re:Subresource Integrity
by throwaway533634 on Friday September 18, 2015 @09:43PM
(#10242983)
None of us would ever indulge in soapbox politics, would we?
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.
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.