When building websites, significant performance gains can be made by using files from a Content Delivery Network (CDN). CDNs usually have nodes much more local (physically) to a visitor, and common files used across many sites (such as jQuery, bootstrap, etc.) may even be already in the visitor’s cache.
However, if you’re using a file from a CDN, well, you don’t really control it. Someone could change it, for honest or nefarious reasons – and your site would still load that resource and try to use it.
Now, the big CDNs are all pretty responsible, but bad things happen – so how can we guarantee that the resource we want the visitor’s browser to load hasn’t been modified?
That’s what Subresource Integrity (SRI) gives us. There’s plenty of details about this at these locations:
…but the short form is that links to the file include a file hash. The browser checks the file it receives against the hash – and disregards it if they don’t match.
However, just disregarding this file leaves us with a problem – if your site relies on jQuery or similar, well, you’ve got a broken site. It really needs fallback.
- It feels like a hack. I mean, the browser know’s it’s rejected the file it received. Is it that hard to have it load from an alternate URL, if provided?
- It’s a pain. As a developer, having to code a fallback each time is a harder than just specifying an alternate URL attribute.
I’m not the first to suggest this, and I doubt I’ll be the last.
Another enhancement to SRI that’s been proposed is that CSPs can also specify that they require-sri-for resources. That’s pretty neat; I can totally see someone forgetting to add SRI to a tag that points to a CDN, and this would make a good way of detecting and fixing those.
However, it seems to me that implementing that should be a lot harder than offering a fallback URL.
Maybe they’ll add it in the future. In the meantime, I guess we have to hack to make it work, or live without fallback.