RE: [Feature Proposal] New attributes "library" and "version" on script tags

# <script src="http://url" sha2="base64-url-encoded_64_byte_hash"></script>
# 5. Any future website, app, or domain requesting the same hash (regardless of URI associated) will be given the cached file instead, with no network request.
# 6. Browsers may choose to implement higher-level caching (such as at the AST level) to eliminate parsing costs associated with popular hashes.

This is much closer already from what I had in mind. 

I would probably ask the file name (aka "lib.js" in http://example.org/scripts/lib.js?v=1.0) to be the same to be sure to lessen the risk of unlikely-but-possible conflicts. Most people using libraries do not rename the file, now they would have a good reason not to ;-)

The only thing I don't like about this is that the hash is included on every page and dissociated from the actual script, and you may update the script on the server while forgetting to update the hash. Another option would be to manage this at the HTTP-level by adding a "If-Hash-Not-In" where the browser would provide a list of hash usually associated to the request file name, and the server would reply with a 304 Not Modified with his own hash (Content-Hash) if one of the proposed hash matches its file. 

That doesn't prevent you from losing some RTT but it's secure by default, and looks closer to how the cache system currently work. Also, browsers could choose to detect when it encounters multiple urls mapping to identical content and generate the hashes locally, so that even non-updated websites benefit from the ability to store things in the cache.

Another benefits is that the server could store a list of possible hashes for the library corresponding the multiple versions known to be working on the website, so that if someone present the v1.1 hash or the v1.0 hash, the server would accept the hash in both cases (assuming the minor version number isn't included in the file name).

Received on Saturday, 10 August 2013 18:31:52 UTC