Correcting possible corruption (e.g. shift reload in Firefox) never uses conditional revalidation and still makes sense to do with immutable objects if you're concerned they are corrupted.
and subresource integrity would insure that the value in the URL matches the hash of the content. Files named by their hash can be treated as immutable with confidence.
How do I do shift reload on my smartphone browser? And how do I even know what shift reload is (most people won't) or that the site is corrupted (it still shows something - how do I know that it isn't the most recent stuff)?
And for my general understanding of this proposal: Even if the current domain owner might guarantee that the content never changes - the domain can switch to another site which might use the pathes but of course wants to put different contents there. Is this somehow covered?
> How do I do shift reload on my smartphone browser?
For some reason, I have the intuition that it's by tapping the address bar (to get text focus) then go/enter/return. But I have no idea if that actually does the equivalent of shift reload!
You can just empty your cache completely - not ideal but still easily done on mobile.
Your 2nd question is confusing - are you asking what happens if you have the same exact path but from another domain? Then it depends on what that server responds with. This is just a HTTP response header, nothing more.
Yeah, I could clean the cache. But most people won't know how - and what a cache even is.
The second question was about that I expected that the new server won't even get queried if the immutable caching policy from the old server prevented this. And so it doesn't have a chance to signal that it's content changed.
The potential for a domain to transfer ownership and still use the same paths, yet have different content seems incredibly unlikely. Like, it feels like you were trying to come up with potential issues for the sake of finding a way to say "see, this won't work!" :P
The biggest reason to use this is for versioned resources. Things that will never change. Say I create a minified JavaScript file. Its MD5 hash is 123456789abcdef...., and so in the output file, the filename is "foo.123456789abcdef.js". If the file changes, the hash changes. If I request the version of the file with "123456789abcdef", I should get that one. Ignoring the unlikely potential for hash collisions, everything in this scenario is working as intended. There is no conceivable reason to ever want to change the content while keeping the same hash.
Now, let's say that file, somehow, gets corrupted AND cached in your browser. I can't say I've ever seen something like this happen, but I suppose it's possible? I'd be very interested to hear if something like this is possible, to be honest. It seems like between TCP retransmissions and Content-Length, you would need some sort of subtle corruption that flips a bit and isn't corrected?
EDIT: As Klathmon points out, Subresource Integrity is probably a better solution to "corrupted file in cache" scenarios. As it stands, if a file was corrupted on disk, let's say, but the ETag and/or the Last-Modified values were accurate, the origin would only ever respond back saying "nope, no changes! you seem to have the latest copy" and you'd still be stuck with the corrupted file. Only a hard reload/cache clear solves that.
I don't want to come up with potential issues just for the sake of preventing this. But it's my job as an engineer to think about all potential issues and to avoid them as long as possible. And I'm not directly involved in this topic here or in the web in the large, but I just read this and have wondered if this is fully thought through or not and asked therefore.
Of course domain changes are unlikely. But nevertheless they are possible in our system and we have to cope with it. I just googled subresource integrity and it doesn't seem like an appropriate solution for this scenario. This would mean a new domain owner would need to generate those for ALL his links - just to be sure that the previous site didn't mess anything up. This means at first extra work and second you wouldn't even know for how long you need this (until all previous users have visited the new site).
There would be even possibilites for major annoyancies, if a previous site owner put that feature on things like index.html before owner change - just to avoid that visitors see the new page as long as possible.
I mean, you could say the same thing about HSTS and key pinning. Domain changes hands, but "oops", HSTS was set and the old keys were pinned.
Is that actually a problem? No, it's not. Similarly, as the owner of a new domain, why would I want the old content? The only reason I can think of is that I brought a company outright, or something. In that situation, if I don't want to change the content, everything still works. If I want to change it, and they did something stupid -- like unversioned paths using this proposed flag -- then yeah, I'm in a weird spot. That seems like the most trivial and unlikely of scenarios, though. It requires such a complex chain of events to occur.
I think it's safe to say that malicious usage of the flag is entirely out of scope when considering the validity of it, again, because it requires a contrived situation.
Of course. But no one sane would put 'Cache-Control: immutable' on `index.html`. It's to be used on `/js/lib/jquery-1.7.1.min.js` or `/js/mystuff-<sha1here>.js` or `/photos/mnbvcxzasdfghjklqqwertyuio1234567890.jpg`
Nobody sane would, intentionally. But I'd bet the house on it happening by accident quite a bit.
At a technical level, I like this idea. When used well, it makes sense to allow. It's hard to fault it without bringing in human error, politics, or economics.
At a practical level...
I can't wait to see what happens when a bug allows Facebook to serve this header on all pages, even for a few minutes. The most Facebook dependant folks around, those checking their phones every five minutes, will be stuck in a perpetual time freeze, unable to move forward ;).
I also can't wait to see what happens when a government tries to ban a cache-control: immutable page.
Or even what happens when, someday, Google is selling it's assets and gets to "google.com.". (Someday, itll happen - Google won't exist for all eternity)
If you can construct an attack out of it, relying on people doing sane things is dangerous... (I'm not sure this is interesting enough as an attack vector, but "but nobody would do that" is a bad answer a lot of the time)
> The potential for a domain to transfer ownership and still use the same paths, yet have different content seems incredibly unlikely.
More generally, many protocols (including basic email verification) break horribly when the assumption that domains last forever gets broken. Ideally, domains shouldn't expire, ever.
EDIT: reading the firefox bug for this test implementation, I'm not sure if it is intended to be applied to pages, or only to sub-resources (early posts mention the distinction, later ones don't)
Correcting possible corruption (e.g. shift reload in Firefox) never uses conditional revalidation and still makes sense to do with immutable objects if you're concerned they are corrupted.
Also, there is Subresource Integrity, which adds a hash to the including tags, and if it is integrated correctly with the caching logic could catch this: https://developer.mozilla.org/en-US/docs/Web/Security/Subres...