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

> Am 13.01.2016 um 06:04 schrieb Kazuho Oku <kazuhooku@gmail.com>:
> 
> 2016-01-13 8:17 GMT+09:00 Amos Jeffries <squid3@treenet.co.nz>:
>> 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).
> 
> That is generally true.
> 
> However the specification will become complicated if we are to include
> the cache digest in the headers, while achieving a good compression
> ratio.
> [...]
> To summarize, the draft utilizes the fact that HTTP/2 multiplexes HTTP
> requests into a single, ordered stream to make things simple.
> Considering the fact that we need to rely on HTTP/2 to push things
> anyways (that is the primary target of the draft), I think that is a
> reasonable trade-off.

There might be use cases to 
a) transport a cache digest over HTTP/1.1
b) expose a cache digest to a web application

I think the draft could define a header field for this purpose
and describe its use. Specifically
- HTTP/1.1 clients should make it a Connection header
- HTTP/1.1 to H2 transformers may use it in calculating their 
  CACHE_DIGEST frames (depending on their caching strategy)
- similar for H2 to HTTP/1.1 gateways

So this header, let's call it "Cache-Digest" for the sake of 
discussion, could appear in HTTP/1.1 requests or on web server
and clients internal APIs:

...
Cache-Digest: <base64url encoded, golombset compressed digests>
Connection: Cache-Digest
...

The question is what a H2 origin server does with such a header, 
should it appear. Ignore, discard?

I don't see that the draft should care about H2 header 
compression efficiency of such a beast. Sending it over H2
seems more a curiosity to me.

-Stefan

> 
>>> * 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.
> 
> Do you consider that caching proxies should establish multiple
> connections to upstream when using HTTP/2?
> 
>> 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
>> 
> 
> 
> 
> -- 
> Kazuho Oku

Received on Wednesday, 13 January 2016 09:41:01 UTC