3 ms·

Thats what ETag is for. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ET...

irq-1 4y ago
ETags can be anything -- they aren't required to be a hash of the content. Thinking about this problem, why does the browser expose any information about what's in the cache? Client-side JavaScript can't tell what's in the cache because it's an obvious security issue. Why let the server know? Browsers should ask for the hashes on a list of content without exposing their cache contents. Then the browser can request anything thats changed.
- jefftk 4y ago
  The way If-None-Match is that the browser says "give me the latest if this ETag represents an out-of-date resource, otherwise I'll keep using my copy." It's not clear to me how you're proposing this work instead? (Also, in many cases the server uses a hash of the inputs to generating the resource, which isn't something externally verifiable)
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 ago
  Neither 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 ago
    You'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 ago
      Well, 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.

irq-1 4y ago

ETags can be anything -- they aren't required to be a hash of the content. Thinking about this problem, why does the browser expose any information about what's in the cache? Client-side JavaScript can't tell what's in the cache because it's an obvious security issue. Why let the server know? Browsers should ask for the hashes on a list of content without exposing their cache contents. Then the browser can request anything thats changed.

jefftk 4y ago
The way If-None-Match is that the browser says "give me the latest if this ETag represents an out-of-date resource, otherwise I'll keep using my copy." It's not clear to me how you're proposing this work instead? (Also, in many cases the server uses a hash of the inputs to generating the resource, which isn't something externally verifiable)

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 ago
Neither 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 ago
  You'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 ago
    Well, 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.