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

Hi,

On Thu, Jun 23, 2016 at 1:32 AM, Mark Nottingham <mnot@mnot.net> wrote:

> 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.
>
>
Ok, sounds sensible.


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


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

My bad! Then definitely I caused some confusion. After your clarifications,
I'm not qualified to answer 2 and 3. But for:

1) Yes, my organization is very interested on this, and we will continue
updating our implementation.

Thanks Mark!

./Alcides.