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 &quot;see, this won&#x27;t work!&quot; :P<p>The biggest reason to use this is for versioned resources.  Things that will <i>never</i> change.  Say I create a minified JavaScript file.  Its MD5 hash is 123456789abcdef...., and so in the output file, the filename is &quot;foo.123456789abcdef.js&quot;.  If the file changes, the hash changes.  If I request the version of the file with &quot;123456789abcdef&quot;, 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.<p>Now, let&#x27;s say that file, somehow, gets corrupted AND cached in your browser.  I can&#x27;t say I&#x27;ve ever seen something like this happen, but I suppose it&#x27;s possible?  I&#x27;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&#x27;t corrected?<p>EDIT: As Klathmon points out, Subresource Integrity is probably a better solution to &quot;corrupted file in cache&quot; scenarios.  As it stands, if a file was corrupted on disk, let&#x27;s say, but the ETag and&#x2F;or the Last-Modified values were accurate, the origin would only ever respond back saying &quot;nope, no changes! you seem to have the latest copy&quot; and you&#x27;d still be stuck with the corrupted file.  Only a hard reload&#x2F;cache clear solves that.