W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

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

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Wed, 13 Jan 2016 10:40:31 +0100
Cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <EDB7D8A6-9121-4268-8920-223E9BE16B19@greenbytes.de>
To: Kazuho Oku <kazuhooku@gmail.com>

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


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

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:10 UTC