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

[Work <[e-mail]>]

Sorry, I should have spoken up on this. I think that ideally the  
length of the domain attribute and the length of the path are the only  
functionally relevant ordering criteria.

In all cases, the most specific cookies ought to come first or web  
applications won't be able to explicitly set a cookie on a given  
domain and expect that siblings can't overturn said cookie.

However, it doesn't seem that specifying new behavior is really in the  
scope of this document, so I'm okay with a SHOULD classification of  
the current most common ad-hoc ordering and a MUST not for server  
dependance on any given ordering.


_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