Consider alternative src value for integrity supported resources #36
3 participants
(Having too many friends that enjoy breaking naive black list filters, I'd hate to be the one adding a new src-ish attribute to HTML
Yeah, it seems better to let developers write this code on their own.
@annevk Well, part of the premise is that developers can't write exactly what they want. To do this alternate-source loading, they have to do it programmaticly, which means they need to either or live without preload scanning (and either use means that they have to preload both resources, which is rather unfortunate).
Not sure this is worth the added complexity, though.
Well, the way things are loaded is drastically changing with services workers and HTTP/2 push. I suspect this will be less of an issue down the road.
cc @esprehn who I know thinks the ability to preload scan these things is important. He can probably make the actual case for this ;-)
For v1, we decided not to consider a non-canonical src feature, but I'd like to raise the prospect of implementing something similar for v2. In particular, I received a request to provide a mechanism for a resource to be loaded from one resource on non-SRI user agents, which is a much more secure server, but on SRI-supporting user agents, to use a faster, less-secure CDN-backed resource.
Such a mechanism could also be used for fallback that we discussed in the original use case, where in the integrity fails for whatever reason from one resource, it would fallback to the other resource.