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

Adam Barth <> Sun, 11 April 2010 16:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A79C63A67D2 for <>; Sun, 11 Apr 2010 09:55:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.623
X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E04uj7XMqYeT for <>; Sun, 11 Apr 2010 09:55:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 403CB3A67A7 for <>; Sun, 11 Apr 2010 09:55:25 -0700 (PDT)
Received: by qyk11 with SMTP id 11so4133165qyk.13 for <>; Sun, 11 Apr 2010 09:55:17 -0700 (PDT)
Received: by with SMTP id gv3mr4320781qcb.87.1271004917378; Sun, 11 Apr 2010 09:55:17 -0700 (PDT)
Received: from ( []) by with ESMTPS id y41sm4728983qce.23.2010. (version=SSLv3 cipher=RC4-MD5); Sun, 11 Apr 2010 09:55:14 -0700 (PDT)
Received: by gwb1 with SMTP id 1so773994gwb.31 for <>; Sun, 11 Apr 2010 09:55:14 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 11 Apr 2010 09:54:54 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Adam Barth <>
Date: Sun, 11 Apr 2010 09:54:54 -0700
Received: by with SMTP id h8mr1625269ybg.136.1271004914389; Sun, 11 Apr 2010 09:55:14 -0700 (PDT)
Message-ID: <>
To: http-state <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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: Sun, 11 Apr 2010 16:55:27 -0000

In the two months since I sent this email, there hasn't been a whole
lot more discussion on this topic.  We discussed the issue at the
working group meeting at IETF77.  Unfortunately, Daniel Stenberg
wasn't in attendance, so we missed out on his perspective.

A number of people (apologies for not recalling who) thought it was
important to specify the ordering.  Various folks had various ideas
about which ordering to use, although most agreed that the specific
ordering is less important than the need to specify an ordering.

My perspective is that we can debate endlessly which ordering to use
even though the particular ordering we choose doesn't matter nearly as
much as getting user agents to interoperate on some ordering.
Therefore, I'm going to leave the ordering requirement in the draft
and specify the ordering that Firefox (and some other browsers) use.
(Note that the draft admonishes server operators not to rely upon the


On Mon, Feb 15, 2010 at 4:47 PM, Adam Barth <> wrote:
> For reasons I don't entirely understand, the order cookies are
> presented in the Cookie header is somewhat controversial.  The
> discussion seems to have quieted down to some extent, so I thought now
> might be a good time to summarize what's been said thus far.
> == General Principles ==
> Daniel Stenberg suggests that we should specify only what needs to be
> specified and leave the rest to the implementors.  In particular, we
> should specify and document what needs to be done in order to work
> with the vast majority of sites, where he takes the "vast majority of
> sites" to be all (except three or more) of the top 500 sites.  He
> appears unwilling to specify a behavior if it's a very rare assumption
> that we can declare a server bug.  However, if sufficiently many
> servers assume that clients behave in a certain way, then we ought to
> specify that behavior.
> In the absence of evidence about what servers require, Adam Barth
> argues that we should specify the most specific behavior that is
> deployed by the most commonly used implementations.
> == Technical Details ==
> Daniel Stenberg agrees that the "most specific" version of two cookies
> with the same name should be sent first.  He agrees that the
> "sort-them-all" approach is the easiest to implement.  Based on this
> experience implementing libcurl, he doesn't think the creation-time of
> a cookie is relevant.
> Dan Winship supports specify the ordering, but mostly on general
> principles rather than specific implementation experience.
> Maciej Stachowiak would like a breakdown of which user agents employ
> which sorting algorithms.  He agues that not specifying the sort order
> isn't viable.
> Anne van Kesteren supports specify the ordering.
> Yngve Pettersen suggests that we continue to specify the ordering, at
> least for path.  Later, he recommends sorting on domain and path,
> ignoring creation-time (because creation-time is less predictable).
> He notes that Opera sorts based on domain first, path second, and
> creation-time third.
> Dan Witte confirms that Firefox sorts by path length and then by
> creation-time.  When Firefox dropped the creation-time sorting in
> 2004, at least one site broke, prompting Firefox to reinstate
> creation-time sorting.  He would be willing to change Firefox to match
> IE because he dislikes creation-time sorting (but implemented it
> because of compatibility issues).
> Paul E. Jones is skeptical that servers will be able to rely on user
> agent sorting behavior and would prefer that user agents never send
> two cookies with the same name.
> Achim Hoffmann notes that the cookie sequence is really important.  He
> is aware of some serious attacks (miss)using the order of cookies.  He
> recommends a specific sorting based on seven factors.
> == Specification Changes ==
> I've added this requirement to the server conformance section:
> [[
>          <t>Although cookies are serialized linearly in the Cookie header,
>          servers SHOULD NOT rely upon the serialization order. In particular,
>          if the Cookie header contains two cookies with the same name,
>          servers SHOULD NOT rely upon the order in which these cookies appear
>          in the header.</t>
> ]]
> == Action Items ==
> 1) Adam Barth will generate the compatibility matrix requested by
> Maciej Stachowiak.
> Adam