Re: Call for Adoption: Cache Digests for HTTP/2

> On 22 Jun 2016, at 09:28, Alcides Viamontes E <alcidesv@zunzun.se> wrote:
> 
> This is bad for several reasons. AFAIK, sites don't have either a way to ask the browser to prematurely evict an expired representation that the browser would otherwise consider fresh. These two things together could allow a cache digest to grow indefinitely. Wouldn't that have a degrading effect on performance?

This is presumably true of caching to begin with, correct? If the browser doesn’t consider the cached representation stale it is welcome to not emit a request for it at all, and simply to serve it from its cache. This means that the cache digest can only grow as large as the client cache allows it to grow, which I should certainly hope is not indefinitely large!

However, it may be sensible to consider providing a SETTINGS field that allows servers to flag a maximum size on a cache digest that it is willing to accept.

> Also related to scoping is the following. Cache digests have been devised so far for a single HTTP/2 Push use scenario: pushing a few assets which are critical to the first render of a page. For that scenario, it is a good idea to keep the digests short. In other words, to not include all assets from the origin that the browser has in cache. Scoping is good here! But there are other HTTP/2 Push scenarios. PUSH_PROMISEs can be sent later on the lifetime of a connection. Since HTTP/2 recommends to not bundle assets, HTTP/2 Push is also handy to push hierarchies of small Javascript modules. Digests are also useful here, but with different assets than the digests at the beginning of a site fetch.

Can you elaborate on this concern, please? For browsers, at least, the only meaningful use of PUSH_PROMISE at this time is to perform cache priming, and the draft allows sending multiple CACHE_DIGEST frames on the connection, which helps keep the server up to date on cache state.

> Another concern we expressed on January was that there was no way to switch off the digest frame. All in all, we think that the current draft is a really good step, and we understand that it doesn't need to be perfect. But if it is not going to be good enough for all scenarios, it would be nice if it can be switched off. Since digests are only used from the second visit to a site, the browser could just remember some hint from the site on previous visits and abstain from using digests.
> 
> For what it counts, and in short, here is our response to the call for adoption:
> 
> - Should be this draft adopted in its current form?:    No.
> 
> - What would be the minimum requirement to revert that response?: A way to switch off digests, so that operators opting for different implementations don't need to pay for it.

Operators using other implementations shouldn’t have to pay for it. RFC 7540 § 5.5 says:

> Implementations MUST discard frames that have unknown or unsupported types.

This means that if a CACHE_DIGEST frame is sent, well-written server implementations will simply ignore that frame. Additionally, servers that do support CACHE_DIGEST will want to be back-compatible with clients that do not emit it for any reason, and so will presumably continue to function as they do now in the absence of CACHE_DIGEST.

That means that “switch it off” amounts to two different things: either don’t emit them as a client (servers can’t make you), or ignore them as a server (client’s can’t think it’s a PROTOCOL_ERROR if a CACHE_DIGEST frame is ignored). So I don’t believe this problem exists in the draft as provided: any implementation that fails in the face of a CACHE_DIGEST frame is violating RFC 7540 by doing so.

Cory