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

On 27/06/2016 8:21 p.m., Alcides Viamontes E wrote:
> 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?
> 

If viewed that way, yes. However the digest itself is not the objects it
lists. It is supposed to be regenerated from the cache state at the
beginning of the newer connection. So objects which have been dropped
out of the cache since that older connection are not even considered for
the new digest.



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

Resetting the whole connection is a huge overhead. Frames with digest
should not really be frequent enough to warrant a whole connnection
close and re-open cycle just to optimize away a single bit per frame.

Having the frame cleared when that huge overhead is being paid anyway
makes sense. But having the dependency the reverse way around would be a
major pain.


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

I susect you are mistaking what "cache" is referring to. There are two
caches involved with these drafts.
* a cache of URL + objects. Stored on the browser.
* a cache of digest values. Stored on the server.

The RESET flag on these frame is about sender controlling the cache of
digest values on the recipient. So it makes no sense to send it from the
agent which holds the cache, to the agent which does not.

It can be used to indicate to the server that the browser objects cache
just got wiped for some unspecified and otherwise irrelevant reason.

Amos

Received on Monday, 27 June 2016 13:21:06 UTC