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

[Work <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>  
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/http-state