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

Hi,

> On 22 Jun 2016, at 6:28 PM, Alcides Viamontes E <alcidesv@zunzun.se> wrote:
> 

[...]

> 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?

It depends on how digests are used. The current idea (reflected in various parts of the draft) is that a client will typically send a cache digest at the beginning of a connection, right after the first request (e.g., for /index.html), but not much afterwards; it's up to the server to track things that it's already sent on the current connection (and indeed some are already doing that). 

If the client caches other responses for the origin during the lifetime of the connection (e.g., on another connection), it can inform the server of this by sending another digest, which does not replace the current one; it's queried alongside any previous digests send on the same connection.

Also, since cache digests are scoped to the lifetime of the connection they're sent within, they can't grow indefinitely, in practical terms. And, of course, servers can discard digests if they don't want to keep the state.

Finally, clients aren't required to represent the complete state of their cache in a digest; they're allowed to choose what representations to include, so (for example) a very large cache can use a heuristic to include only the most likely candidates in a digest, to limit its size.


> 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?

Yes; see the RESET flag.


> 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. 

Yes. As mentioned above, the set of digests on the server can be added to non-destructively.

One of the reasons we have a fair amount of flexibility in how the format works -- and thus so many flags (Hi, Martin), is that it's difficult to predict all of the different ways they'll be used, and we want to assure that they can address a variety of scenarios. With some implementation experience and wider deployment, we can refine what's there, of course.


> 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. 

Hmm. We'd effectively need a site-wide, persistent hint to indicate that future visits should include digests. That actually dovetails pretty well with some other ongoing conversations (this kind of requirement comes up often); let me try to write something down.


> 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. 

<chair hat on>

OK. For what it's worth, a CfA is asking whether the WG should start work in an area; it's not saying that the exact document is going to turn into the standard. Most drafts we adopt undergo substantial changes in the WG process, sometimes to the point where the original document is unrecognisable. 

As such, the CfA is really looking for a few things: 1) is there enough interest in doing it, and are there potential implementers?  2) Are there any red-flag issues (e.g., pushback from the Security area) that would make starting the work counter-productive?  3) Is the draft mature enough to make WG discussion productive?

Cheers,


--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 22 June 2016 23:32:42 UTC