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

I just came gain over these emails and there are a few things which I don't
completely understand.


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

Isn't the cache supposed to contain assets obtained during previous visits?
In that case, wouldn't the cache digest contain assets that the browser
obtained in a previous connection?



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

I went to the draft to understand better the RESET flag. What is the
typical scenario that this flag is intended for? I can see that RESET helps
if something happens to the cache; then the browser can use the flag to
tell the server. But is the browser supposed to clear the cache often in
the middle of a connection? If not, how is this substantially better than
just resetting the connection? .. Both Chrome and Firefox reset connections
when the user clears the cache.

Also, if the server idea of assets held by the browser is bigger than the
assets actually held by the browser, the assets won't be pushed, but the
browser can just request them "normally".

What I was alluding before was close to having the RESET in the other
direction, from server to browser, to ask the browser to clear its cache
for the current origin. This could be good for a number of use cases, not
least of them decreasing the chance of false positives in queries to the
digest. But adding a mechanism for the server to clear the browser's cache
may be a bit out of scope :-( ...