4 ms·
I think it would actually make more sense for the sha256 to be in the headers for setting it. It seems a bit weird for a property on a link tag pointing at a fi
by ZoFreX 14y ago
I think it would actually make more sense for the sha256 to be in the headers for setting it. It seems a bit weird for a property on a link tag pointing at a file to determine what we think the hash of that file is (not to mention quite un-fun to maintain).
Of course, that means without duplicating it you would still need a request similar to If-Modified-Since - something like If-Hash-Differs: <sha256 hash>, but still better than downloading the whole file.
I've thought about this exact problem before and one nice way to solve it would be through some kind of signing process - so you instead tell the browser "I need com.jquery.1.7.2" and there would be some way of verifying that a given instance of that file was legitimate, and could thus be cached across multiple URIs.
- SoftwareMaven 14y agoI agree the thing serving foo.js should be setting its sha hash in the headers. The client can validate that the header hash and the actual contents match, if it so desires. On the web application side, by putting a "sha" tag in the script tag, the app is saying, "Fail if foo.js isn't the one I expect, regardless of where it comes from." By putting a "shared_cached" in the script tag, the app is telling the client where it is allowed to look for and to put foo.js. Finally, a client should be able to ignore any shared cache requests and make everything private at the user's request.