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: Chris Bentzel <chris@bentzel.net>
Date: Mon, 11 Jan 2016 05:42:20 -0500
Message-ID: <CABCZv0piAoDnA1J+2pJ3HyF_iRwj9AaFGfonFjdKGfYr=cGZgQ@mail.gmail.com>
To: Cory Benfield <cory@lukasa.co.uk>
Cc: Alcides Viamontes E <alcidesv@zunzun.se>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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
Received on Monday, 11 January 2016 10:42:49 UTC

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