Re: [http-state] Ticket 5: Cookie ordering

Daniel Stenberg <> Wed, 20 January 2010 08:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18EA23A68C7 for <>; Wed, 20 Jan 2010 00:14:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yOYF+b--x4po for <>; Wed, 20 Jan 2010 00:14:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 773813A68A9 for <>; Wed, 20 Jan 2010 00:14:04 -0800 (PST)
Received: from ( []) by (8.14.3/8.14.3/Debian-9) with ESMTP id o0K8Duff019026; Wed, 20 Jan 2010 09:13:56 +0100
Date: Wed, 20 Jan 2010 09:13:56 +0100 (CET)
From: Daniel Stenberg <>
To: Adam Barth <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
X-fromdanielhimself: yes
MIME-Version: 1.0
Content-ID: <>
Cc: http-state <>
Subject: Re: [http-state] Ticket 5: Cookie ordering
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Jan 2010 08:14:06 -0000

On Tue, 19 Jan 2010, Adam Barth wrote:

> Let me try rephrasing your proposal to make sure I understand it properly:
> (4) Require that among cookies with the same name, user agents ought
> to present cookies with longer path attributes before cookies with
> shorter path attributes.  The spec should not require or recommend
> other ordering constraints.
> Can you explain why (4) provides a better cost / benefit trade-off
> than (1) or (3)?  In particular, what is the advantage of us adopting
> (4) over (1) or (3)?

I like specifying only what needs to be specified and leave the rest to the 
implementor. In every spec I read or work with.

The (3) "sort-them-all" approach is indeed the easier way to implement this, 
as figuring out exactly which cookies that have the same name and only 
special-case the order of those will probably be a bigger effort than to 
simply unconditionally sort all cookies based on path length.

Since the only cookies that NEED an order are those that have the same name, I 
think we should only specify that.

> Do you have data about the relative compatibility of (1), (3), and (4)?  If 
> not, are you willing to generate this data?  It seems like there is some 
> interoperability / compatibility risk to (4) that would be mitigated in (3) 
> and (1).  Without a way to quantify this risk, we are flying blind.

I've not seen anyone present any numbers regarding cookie sort order so I 
don't quite see why I would be different here. No, I don't have any numbers 
and I don't think I'm able to come up with any numbers either.

My assumptions and views of reality here comes from the fact that I've written 
a cookie implementation that has been used rather widely by applications, 
frameworks and browsers for quite a number of years by now. Like most other 
people here base their views on work with other implementations and/or users. 
I assume we're all similar in that aspect.

>> I don't think it needs to say that _all_ cookies need to be sorted on path
>> length, as that's not what servers need.
> Why introduce interoperability problems where none exist?

The interoperability here is against servers. Can you show me two servers in 
active use today that a client doesn't work with if the cookie order is as 
"free" as I suggest?

> If the most widely used user agents are already doing something sensible

Web user agents, browsers, sure. There is also a wide range of non-gui clients 
that use HTTP and cookies that we don't know how much they're used and as I 
showed before, lots of them have no sorting whatsoever and lots of them work 
fine against the vast majority of the cookie-using sites out there.

I don't think browser usage share is the only and final measurement here.

(I should add that curl will sort cookies based on path length starting soon, 
as I've been convinced that there will be a few rare sites that cannot work 
properly without it.)

Some of those non-web tools that deal with cookies know how to import cookies 
from the traditional cookies file in the netscape file format, and that format 
has no "creation time" field and thus importing cookies from such a file makes 
it impossible to send the cookies back sorted on the original "creation time" 
but instead it could only do it based on the time of the read from a file.

> I'm sure there's a site somewhere that depends on the consensus ordering.

In my view there is no consensus ordering.

> A common case is that a server will send two Set-Cookie headers in the
> same HTTP response:
> Set-Cookie: foo=bar
> Set-Cookie: baz=qux
> With sort order (1), the user agent will respond
> Cookie: foo=bar; baz=qux
> or omit the cookie header entirely.  I can easily imagine server-side code 
> that would break if presented with "Cookie: baz=qux; foo=bar".

Really? I mean, sure I can imagine that there is also sites that require that 
the Cookie: header is the 5th header in the request but that doesn't make it a 
correct assumption even though it might work with a browser or two.

Is it really an assumption that is widely enough used so that we need to 
document it as something clients should do?

I'm only against specifying it in the spec if it's a very rare assumption that 
we can declare is a server bug. If the assumption is spread and used more than 
rarely then I am wrong and it should be specified.

> The easiest way to work with all servers is to sort the cookies as proposed 
> in (1).

The easiest way is to just document the exact behavior of one browser and one 
server implementation and we're done. That's however not our job here, I