3 ms·
ETag doesn't have any assurance that it's a hash of the page contents: the current protocol doesn't stop the server from embedding arbitrary information in the
by jefftk 4y ago
ETag doesn't have any assurance that it's a hash of the page contents: the current protocol doesn't stop the server from embedding arbitrary information in the ETag, and there's no way for the client to tell.
- debugnik 4y agoNeither does Last-Modified, as we just saw. If we were going to alter the meaning of a header for this, it should be ETag. Just agree on ETag formats that browsers can verify are just hashes, and have them throw away any opaque ETags or dates.
- jefftk 4y agoYou'd need to introduce something new for that. Many servers compute ETags today as hashes of inputs to a process. (Which is nice computationally, since you can immediately say "not modified" instead of building the response, hashing it, and throwing it away if the hash matches)
- debugnik 4y agoWell, I said "just hashes" for sort, but such ETag formats could agree on other algorithms as well, as long as the browser can verify them. And introducing a new method doesn't solve the issue of deprecating the existing abusable methods, which is why I suggested one that can already be implemented by privacy-first browsers one-sidedly. Servers would then be pressured to migrate to some friendly ETag format if they don't want to completely lose client-side caching for a (hopefully growing) share of their userbase.