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

Work <mpauley@apple.com> Sun, 11 April 2010 18:59 UTC

Return-Path: <mpauley@apple.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E51443A6890 for <http-state@core3.amsl.com>; Sun, 11 Apr 2010 11:59:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.299
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tg43HyEg2Ybl for <http-state@core3.amsl.com>; Sun, 11 Apr 2010 11:59:00 -0700 (PDT)
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id E91643A67FA for <http-state@ietf.org>; Sun, 11 Apr 2010 11:58:59 -0700 (PDT)
Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id 827779495484 for <http-state@ietf.org>; Sun, 11 Apr 2010 11:58:55 -0700 (PDT)
X-AuditID: 11807134-b7bbbae0000026d3-f5-4bc21befd525
Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay14.apple.com (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 [10.67.181.162] (166-205-136-173.mobile.mymmode.com [166.205.136.173]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L0Q00K5O7E1Q500@et.apple.com> for http-state@ietf.org; Sun, 11 Apr 2010 11:58:55 -0700 (PDT)
References: <5c4444771002151547k75bbd0e7rfd2ccf735bdb2e37@mail.gmail.com> <u2o5c4444771004110954tfbb069ddj6f80356bc4bd47d3@mail.gmail.com>
Message-id: <F06CA34F-F657-482E-8639-B3932D1141CF@apple.com>
From: Work <mpauley@apple.com>
To: Adam Barth <ietf@adambarth.com>
In-reply-to: <u2o5c4444771004110954tfbb069ddj6f80356bc4bd47d3@mail.gmail.com>
X-Mailer: iPhone Mail (7E18)
Date: Sun, 11 Apr 2010 11:58:42 -0700
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: http-state <http-state@ietf.org>
Subject: Re: [http-state] Summary of discussion of Ticket 5 (Cookie ordering)
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=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.

_Mark

On Apr 11, 2010, at 9:54 AM, Adam Barth <ietf@adambarth.com> 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 <ietf@adambarth.com>  
> 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
> http-state@ietf.org
> https://www.ietf.org/mailman/listinfo/http-state