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

[Kazuho Oku <[e-mail]>]

2016-01-12 0:39 GMT+09:00 Ilya Grigorik <[e-mail]>:
> 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
* cache state is an information that is bound to the connection, not
to a request

There are hacks that be used to evade such problems:

* use multiple headers (send a big constant + small delta that changes
frequently) to represent a single digest for HPACK efficiency
* do not send cache digest if it is likely than an intermediary exists

but I do not think we should include such things in the spec.

> ig
>
> On Mon, Jan 11, 2016 at 2:42 AM, Chris Bentzel <[e-mail]> wrote:
>>
>> The draft does cover some privacy concerns (such as clearing the digest
>> when cookies are cleared).
>>
>> One concern not covered is how to deal with cases where a client may have
>> cached content from an origin with a mix of cookies. For example, if a user
>> has enabled third-party cookie blocking in a browser and has visited an
>> origin in both a first-party and third-party context there may be a mix of
>> cached content with a session identifier cookie and no cookie.
>>
>> If the user re-visits that origin in a first-party context, the digest may
>> reveal content retrieved in a third-party context.
>>
>> One option is to treat cached content as if there is an implicit Vary:
>> Cookie header and only include in the digest if it matches. The draft
>> already requires only including fresh cached entries in the digest so a
>> selection process for cached entries already will need to exist.
>>
>> On Mon, Jan 11, 2016 at 3:16 AM, Cory Benfield <[e-mail]> wrote:
>>>
>>>
>>> > On 10 Jan 2016, at 17:11, Alcides Viamontes E <[e-mail]>
>>> > wrote:
>>> >
>>> > Can we embed the cache digest in a header?
>>> > ——————————————————————————————
>>> >
>>>
>>> On a personal level I am extremely nervous about shoving 24kB of data
>>> into a header value. The practice of doing this for Kerberos tokens already
>>> caused us to require the CONTINUATION frame unpleasantness in RFC 7540.
>>> Generally speaking it seems like smuggling long strings in HTTP headers is a
>>> bit of an anti-pattern, and given that HTTP/2 gives us much nicer methods of
>>> transporting this kind of data it seems a shame not to use them.
>>>
>>> Cory
>>>
>>
>



-- 
Kazuho Oku