Re: [http-state] Summary of discussion of Ticket 5 (Cookie ordering)

Adam Barth <> Fri, 16 April 2010 16:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 728243A69ED for <>; Fri, 16 Apr 2010 09:44:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.424
X-Spam-Status: No, score=0.424 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_50=0.001, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2cNVXtkuJl24 for <>; Fri, 16 Apr 2010 09:44:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 540B428C148 for <>; Fri, 16 Apr 2010 09:44:51 -0700 (PDT)
Received: by bwz25 with SMTP id 25so3356766bwz.28 for <>; Fri, 16 Apr 2010 09:44:39 -0700 (PDT)
Received: by with SMTP id n23mr2024548bkt.43.1271436278917; Fri, 16 Apr 2010 09:44:38 -0700 (PDT)
Received: from ( []) by with ESMTPS id s17sm1612072bkd.16.2010. (version=SSLv3 cipher=RC4-MD5); Fri, 16 Apr 2010 09:44:38 -0700 (PDT)
Received: by pzk31 with SMTP id 31so1422931pzk.31 for <>; Fri, 16 Apr 2010 09:44:35 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 16 Apr 2010 09:44:15 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Adam Barth <>
Date: Fri, 16 Apr 2010 09:44:15 -0700
Received: by with SMTP id k17mr1949948waf.31.1271436275295; Fri, 16 Apr 2010 09:44:35 -0700 (PDT)
Message-ID: <>
To: Achim Hoffmann <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Daniel Stenberg <>, http-state <>
Subject: Re: [http-state] Summary of discussion of 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: Fri, 16 Apr 2010 16:44:54 -0000

On Fri, Apr 16, 2010 at 3:29 AM, Daniel Stenberg <> wrote:
> On Fri, 16 Apr 2010, Achim Hoffmann wrote:
>> I'd recommend that the spec does not recommend the cookie ordering.
> I strongly agree with this. It just seems that we're a minority and we can't
> get stuck on the sorting issue forever...

Indeed.  We're way off in the weeds on this issue.

On Fri, Apr 16, 2010 at 8:14 AM, Achim Hoffmann <> wrote:
> Sorry, have to disagree here.
> See my (still unanswered) posting
> and if we look at the posting in this thread, we see that the ordering is
> not unique anyhow.

Here's how I would respond to your email:

] Does somebody know a paper/link where I can find a definition how browsers
] (should) send cookies?

] For example Mozilla/FF seems to send the cookies in this order:

I don't believe you've done your reverse engineering correctly (or
maybe the behavior has changes since you wrote that email).

] Above examples are just a small set of tests, I guess that following
] are used somehow, somewhere also:

I don't believe that's correct.

] All these variations make tests complicated, that's why I'm asking if there
] exists a rule or alike.

Indeed.  That's why having everyone reverse engineer everyone else's
implementation is no good for interoperability, which is why we
started this working group.  :)

> IIRC the purpose is to write down the status quo today.

That's correct.  Does the current text of the draft not reflect the status quo?

> If the spec says "MAY have any order", they don't need to read the spec,
> and security analysts can always blame the application developer without
> refering the specs if something went wrong ;-)

The spec already requires that servers not depend on the ordering.  If
you're interested in the blame game (which I'm not), the spec already
gives you grounds for blaming the application developer.

On Fri, Apr 16, 2010 at 3:11 AM, Achim Hoffmann <> wrote:
> hmm, this description leads me to following example:
>  * cookies send by www.some.tld in following chronological sequence
>        Set-Cookie: key=val0;
>        Set-Cookie: key=val1; path=/foo
>        Set-Cookie: key=val2; path=/
>        Set-Cookie: key=val3; path=/bar
>        Set-Cookie: key=val4; domain=.some.tld
>        Set-Cookie: key=val5; domain=.some.tld; path=/some/thing/very/long/to/ensure/being/first

I've converted your test case to test ordering0001:

Set-Cookie: key=val0;
Set-Cookie: key=val1; path=/cookie-parser-result
Set-Cookie: key=val2; path=/
Set-Cookie: key=val3; path=/bar
Set-Cookie: key=val4;
Set-Cookie: key=val5;; path=/cookie-parser-result/foo
Location: /cookie-parser-result/foo/baz?ordering0001

I don't think it's possible for both val1 and val3 to appear in the
same Cookie header because neither is a prefix of the other.

>  * cookies send by user agent for a request to http://www.some.tld/
>        Cookie: key=val5; key=val1; key=val3; key=val2; key=val0; key=val4

Here's the ordering that Internet Explorer, Firefox, and Chrome produce:

Cookie: key=val5; key=val1; key=val2; key=val4

Notice that the ordering matches the spec.  The cookie with val3 is
missing because /bar is not a prefix of the result URL (we have a
choice of either getting val1 or val3).  The cookie with val0 is
missing because the cookie is set from the path "/cookie-parser",
which gets a default path of "/" and so gets overwritten by val2.

> I guess (but did not yet prove) that most browsers do not send cookies in this
> (above) sequence. It would rather be:
>        Cookie: key=val3; key=val1; key=val2; key=val0; key=val5; key=val4
> So the new description does not show current practice.

Perhaps you should run your test cases instead of making bold claims
like the above.

> According application security, I already explained that web applications which
> rely on the ordering somehow, are prone to some attacks.

Which is why we require servers not to rely on the ordering.

> As there is no common behaviour according this ordering in current browsers, I'd
> recommend that the spec does not recommend the cookie ordering. This is not wrong
> and would force web application developers to implement proper measures:
>        User agents MAY send cookies in any sequence.

Do you have test cases that demonstrate that there is no common
ordering?  The test case that you presented above does not behave as
you claim.

> KISS - keep it simple, stupid

The cookie protocol is far from simple, but that's just how the world
is.  If I were designing a state management protocol today, I would
design something that was one or two orders of magnitude simpler.