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

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