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

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

ig

On Mon, Jan 11, 2016 at 2:42 AM, Chris Bentzel <chris@bentzel.net> 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 <cory@lukasa.co.uk> wrote:
>
>>
>> > On 10 Jan 2016, at 17:11, Alcides Viamontes E <alcidesv@zunzun.se>
>> 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
>>
>>
>