Subject: [httpwg/http-extensions] [cache-digests] Remove ETag from the digest key calculations (#516)

From: HTTP issue updates <[email-masked]>
Date: Sun, 18 Mar 2018 05:17:44 -0700

Having ETags as part of the digest key adds a lot of complexity to the Cache Digest implementation both on the client and the server:
* Clients may not have the ETag readily available at removal time, which would mean removal from the digest introduces I/O operations and slowness.
* Servers may not have the ETag readily available when they want to send down push promises, forcing them to make those conditional on I/O operations (and again, slowness).

I [ran an HTTPArchive analysis](https://discuss.httparchive.org/t/cacheability-of-render-critical-resources/1278) and it seems that from the render-critical resources that are push candidates, 77.26% of them are cacheable for at least 24 hours.
Same query with 30 days minimal freshness gives us 52.32% of the resources.

So it seems that servers can in many cases have enough render-critical resources to push even without the ETag info.
Therefore I suggest removing it, to simplify implementations. If we'd see that it becomes an issue in the future, we could add it back as optional.

Thoughts?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/516

---

From: HTTP issue updates <[email-masked]>
Date: Tue, 20 Mar 2018 10:19:43 +0000 (UTC)

> So it seems that servers can in many cases have enough render-critical resources to push even without the ETag info.

I agree.

Note also that it is difficult to use a digest of freshly cached responses that uses ETag due to lack of agreement on if we can push a response to replace a freshly cached object within the client's cache. See the chart on https://datatracker.ietf.org/meeting/101/materials/slides-101-httpbis-cache-digest-00 page 7.

> Therefore I suggest removing it, to simplify implementations. If we'd see that it becomes an issue in the future, we could add it back as optional.

The reason we allow the use of ETag is to support sending a digest of stale responses. When a server receives a digest of stale responses, a server needs to decide if it pushes a 200 or "not modified", based on the value of ETag.

In other words, removal of ETag support needs to come along with removing support for stale digests. That said, I do not oppose to removing them altogether (means that we will only allow sending a digest of freshly-cached responses that uses HASH(URL) as the key), considering the fact that how to push a "not modified" signal is not something that the community has agreed.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/516#issuecomment-374545183