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

A 512-bit SHA-2 hash cannot have conflicts. Filename matching would make
the feature unreliable, adding another point of failure.

There's also no point this feature if you move it to the HTTP layer; it
only provides a benefit if (a) eliminates network traffic and (b) securely
identifies a file across multiple websites so (c) browsers can implement
higher-order caching.

Think about how *trivial* it is to implement a text editor plugin that
updates these hashes. Every language has can make an HTTP request, every
language can do SHA-2. CMSes, IDEs, text editors, even accelerator proxies
can handle the maintenance of these hashes. A few months after browser
support is introduced, it will just be a keystroke combination like code
reformatting. Most of the web runs CMSes, and they will handle it invisibly.

Mismatches don't get optimized, it's as simple as that. Don't optimize the
optimization, keep it simple.

Best regards,
Nathanael


On Sat, Aug 10, 2013 at 2:31 PM, François REMY <
francois.remy.dev@outlook.com> wrote:

> # <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).
>