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

[Alcides Viamontes E <[e-mail]>]

Hello,

I'm sorry to have to intervene now, since as part of a publicly financed
project my company is trying to build forecasts on how cache digests would
work in practice. We are extrapolating data from a few scanned websites.
The goal is to get likely bounds for the sizes of cache digests.

We also have some data from using a cookie implementation of cache digests
in ShimmerCat that follows this draft closely. We are satisfied with how it
works but we have identified a few things that can be improved.

We expressed some of our concerns in January, and we are glad to see that
some of them have been addressed, i.e. the inclusion of validators.

A further concern was scoping: as it stands now, the only scoping mechanism
for digests is to use different origins.

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?

We turn on cache digests during development, and we have seen the cache
digests grow due to the accumulation of different versions of assets.
Because we are using a cookie implementation, we can have the server reset
the cookie when it gets too big. Would that be possible  with the current
draft?

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.

Another concern we expressed on January was that digests as an HTTP/2 frame
are something that suits well large and well-equipped infrastructure
operators but that becomes almost invisible and hard to debug for web
developers and sysadmins with less resources. However we can swipe that
concern under the rug by hoping that browser tooling will catch up
eventually.

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.



On Wed, Jun 22, 2016 at 8:52 AM, Mark Nottingham <[e-mail]> wrote:

> <https://tools.ietf.org/html/draft-kazuho-h2-cache-digest-01>
>
> This draft has been discussed both out in the community and at our
> meetings, and there seems to be a decent amount of interest in it. So, this
> is a Call for Adoption to add it to our set of working documents.
>
> Please state whether you support adoption, and ideally why. Expressions of
> interest in implementation would also be very helpful.
>
> We'll wait at least one week before making a decision.
>
> N.B. Because I'm co-author on the draft, Natasha Rooney has kindly agreed
> to judge consensus on the CfA, and act as Document Shepherd if we do adopt
> it.
>
> Cheers,
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>