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

2016-01-14 6:03 GMT+09:00 Ilya Grigorik <ilya@igvita.com>:
>
> On Wed, Jan 13, 2016 at 1:40 AM, Stefan Eissing
> <stefan.eissing@greenbytes.de> wrote:
>>
>> > 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.

I like Stefan's proposal to include a definition of how Cache Digest
should be encoded as a header.

Defining it will increase the flexibility of how the value can be used.

> Agreed. As was highlighted previously, exposing it via a header makes it
> accessible to web developers (and removes the requirement for UA to support
> this "natively" to get any benefit or use), which (to me, at least) far
> outweighs the benefits of saving a few bytes.

I understand your points.

However, the issue is that the information is hop-by-hop.  In terms of
HTTP/1, a header specifying the cache digest should be included in the
`Connection` header.  However, both XMLHttpRequest and Fetch API (IIRC
on which ServiceWorker depends) disallows applications to modify the
Connection header.

So a SW trying to send cache digest needs to send the value without
designating it as a hop-by-hop header.  And that means that if a H2
origin server sees the header, it needs to determine if the request
came through an intermediary, and only use the value if it did not.
Or else, a server might end up repeatedly pushing resources to a
caching proxy that already has them cached.

This looks like a hack to me, and I am not sure if it should be
permitted within a specification, even though I believe it would work
effectively (as we are doing in H2O).

> ig



-- 
Kazuho Oku

Received on Thursday, 14 January 2016 08:55:49 UTC