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

Work <> Sun, 11 April 2010 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E51443A6890 for <>; Sun, 11 Apr 2010 11:59:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.299
X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tg43HyEg2Ybl for <>; Sun, 11 Apr 2010 11:59:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E91643A67FA for <>; Sun, 11 Apr 2010 11:58:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 827779495484 for <>; Sun, 11 Apr 2010 11:58:55 -0700 (PDT)
X-AuditID: 11807134-b7bbbae0000026d3-f5-4bc21befd525
Received: from ( []) by (Apple SCV relay) with SMTP id 13.36.09939.FEB12CB4; Sun, 11 Apr 2010 11:58:55 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Received: from [] ( []) by (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <> for; Sun, 11 Apr 2010 11:58:55 -0700 (PDT)
References: <> <>
Message-id: <>
From: Work <>
To: Adam Barth <>
In-reply-to: <>
X-Mailer: iPhone Mail (7E18)
Date: Sun, 11 Apr 2010 11:58:42 -0700
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: 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: Sun, 11 Apr 2010 18:59:01 -0000

As an aside CFNetwork does return cookies of the most specific domain  
first, that much is clear from the code. I don't think that it's as  
clear that we send cookies with the longest paths first however.


On Apr 11, 2010, at 9:54 AM, Adam Barth <> wrote:

> 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
> ordering.)
> Adam
> 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
> _______________________________________________
> http-state mailing list