W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Cookie crumbling

From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Wed, 23 Oct 2013 01:33:11 +0900
Message-ID: <CAPyZ6=JyJNpF0NtrP8ft0JFivgUSjW6kDoitfzgYbh5ooTjz6g@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Roberto Peon <grmocg@gmail.com>
On Wed, Oct 23, 2013 at 12:58 AM, Martin Thomson
<martin.thomson@gmail.com>wrote:

> On 22 October 2013 05:18, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
> wrote:
> > RFC 6265 says the client should sort cookie in a certain way:
> > http://tools.ietf.org/html/rfc6265#section-5.4
> >
> > Since the header compressor does not preserve the ordering of the
> headers,
> > we lose the cookie ordering.
> > I'm not really sure how important the cookie ordering today or future
> > though.
>
> I'm sure that the only reason that requirement exists is to reduce the
> fingerprinting surface of the client.
>
> The good part with that ordering requirement is that it makes it
> perfectly clear that ordering carries no semantics.
>
> I'm sure that an intermediary or API that translates to HTTP/1.1 can
> reorder anything that might get messed around by HTTP/2.0 header
> compression.
>

If "reorder anything" means "restore the original ordering",
I think the intermediary in this case cannot restore the reordering of the
cookie as the browser sent them.
This is because the information to correctly order the cookie in RFC
fashion is only kept by the browser and is stripped away when cookies are
sent out in Cookie header field.

Best regards,
Tatsuhiro Tsujikawa
Received on Tuesday, 22 October 2013 16:33:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC