Re: Submitted new I-D: Cache Digests for HTTP/2

[Amos Jeffries <[e-mail]>]

On 12/01/2016 2:20 p.m., Kazuho Oku wrote:
> 2016-01-12 0:39 GMT+09:00 Ilya Grigorik:
>> Glad to see this proposal!
>>
>> FWIW, another +1 for enabling this functionality via an HTTP header.
>> Limiting it to h2 frames makes it effectively inaccessible to web developers
>> that want to experiment with own cache management logic (via ServiceWorker,
>> etc).
> 
> Glad to hear from you.
> 
> While it is possible to use an HTTP header to implement cache-digest
> (and that is what we are doing now in H2O + ServiceWorker/cookie), I
> believe it should ideally be implemented as an HTTP/2 header since:
> 
> * including the digest value (the value changes as client receives
> responses) in every HTTP request is a waste of bandwidth

Bandwidth may or may not be a problem relative to the digest design and
amount of compression applied by the protocol (eg. h2 dynamic table vs
HTTP/1.1 repetition).


> * cache state is an information that is bound to the connection, not
> to a request

You assume a browser endpoint cache.

Intermediary caches are constructed from content flowing over multiple
parallel connections. Potentially from multiple origins. Which makes it
very likely to have changed between any two given requests to contain
things that cannot be inferred by the server from those two requests.

This type of problem is also more likely to happen in the presence of
domain sharding. Where the temporal locality of the index request is
different from the 100's of content requests.

ALTSVC may also make similar things happen with browser caches.

Amos