Subject: Cookie crumbling

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Oct 2013 15:38:48 -0700

Turns out that splitting the Cookie header into pieces improves
compression efficiency considerably. It also turns out that we haven't
done that, despite talking about it, testing code with it, etc...

Just raised an issue to track this:
https://github.com/http2/http2-spec/issues/292

I think that we've had agreement to do this in the past, but it's been
suspiciously absent from the compression draft.  Roberto hopes to be
able to work this part out for the post-Vancouver/88 version of the
drafts.

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Tue, 22 Oct 2013 21:18:10 +0900

> able to work this part out for the post-Vancouver/88 version of the
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.

Best regards,
Tatsuhiro Tsujikawa

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 22 Oct 2013 14:25:23 +0200 (CEST)

> I'm not really sure how important the cookie ordering today or future 

I fought for us to leave out the sorting from the spec since I believe it is 
wrong and never what was intended. But I "lost" and that sorting is now in the 
cookie RFC.

Clearly there are enough big sites out there that depend on the sorting so it 
won't be easy to just silently remove it. And all browsers sort them already. 
But I also think that cookies are usually sent from browers to the server in a 
single header.

-- 

  / daniel.haxx.se

---

From: Zhong Yu <[email-masked]>
Date: Tue, 22 Oct 2013 08:54:26 -0500

The ordering is apparently arbitrary and nonsensical. Even if the
ordering matters for some servers, it probably only matters within
cookies of the same name. Why would it matter to any server whether
cookie "a" is sent before cookie "b" or after?

On Tue, Oct 22, 2013 at 7:25 AM, Daniel Stenberg <[email-masked]> wrote:
> wrong and never what was intended. But I "lost" and that sorting is now in
> the cookie RFC.
>
> Clearly there are enough big sites out there that depend on the sorting so
> it won't be easy to just silently remove it. And all browsers sort them
> already. But I also think that cookies are usually sent from browers to the
> server in a single header.
>
> --
>
>  / daniel.haxx.se
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Oct 2013 08:58:02 -0700

> I'm not really sure how important the cookie ordering today or future

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.

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 23 Oct 2013 01:33:11 +0900

> reorder anything that might get messed around by HTTP/2.0 header

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Oct 2013 09:39:23 -0700

> cookie as the browser sent them.

The order is canonical.

       *  Cookies with longer paths are listed before cookies with
          shorter paths.

       *  Among cookies that have equal-length path fields, cookies with
          earlier creation-times are listed before cookies with later
          creation-times.

It's trivially possible to recreate a canonical form.

---

From: James M Snell <[email-masked]>
Date: Tue, 22 Oct 2013 09:45:12 -0700

> It's trivially possible to recreate a canonical form.

This needs to be documented quickly in the spec. I suspect that there
are many implementers out there who may miss this subtle detail.

- James

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 22 Oct 2013 19:58:01 +0200 (CEST)

> It's trivially possible to recreate a canonical form.

No.

As Tatsuhiro pointed out, that information is not conveyed in that header sent 
from the client so the sort order is completely impossible for anyone else 
than the client to know. The paths and creation times could've been sent weeks 
ago.

So if you scramble the order, there's actually no way to put them back in the 
correct order.

-- 

  / daniel.haxx.se

---

From: James M Snell <[email-masked]>
Date: Tue, 22 Oct 2013 11:11:07 -0700

FWIW, I experimented with an alternative to the existing
set-cookie/cookie mechanism that used an extension frame type with
it's own isolated compressed header block and typed codecs and
achieved a roughly 40-70% improvement (depending on cookie content) in
compression ratio over the current cookie crumbling approach.

Personally, I'd much rather -1 the cookie crumbling as a premature
optimization and explore alternative approaches later on once we have
a better defined extension model.

- James

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Oct 2013 15:26:35 -0700

> compression ratio over the current cookie crumbling approach.

You are describing just one potential solution to the problem.  You'll
note that the issue doesn't make a statement about how the problem is
solved, just that we need to determine whether we need a solution, and
- if so - what that solution looks like.

> a better defined extension model.

We decided to talk about extensions in Vancouver.  But your -1
presupposes that you need an extension frame (and not a modification
to a header block, for instance.