3 ms·

This issue is discussed here, with what I think is a workable solution: https://github.com/w3c/webappsec-subresource-integrity/issues/22 https://github.com/w3c/

• wanderr 10y ago
  I think the best way to fully quell the objections involves subresource integrity but I think the ideal way to deal would be to add a new attribute, sameas="https://canonical https://canonical jquery link" or something along those lines. Then if the browser already has canonical jquery link AND the subresource integrity checks out it'll use that one. Otherwise it will load from wherever the developer specified and not be stored in a shared cache associated with the canonical jquery url in any way. Browsers can track references to sameas URLs that they keep getting cache misses on and go fetch them in the background for future use, possibly even going back and deleting the duplicates it had from before. This would allow developers to have a much greater chance that their libraries load from cache without adding more dns lookups and dependencies on cdns or servers they can't control.