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

[Adam Barth <[e-mail]>]

On Sun, Apr 11, 2010 at 11:53 AM, Work <[e-mail]> wrote:
> 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.

We've generally shied away from MUST-level requirements for server
operators.  For example, we don't even have a MUST-level requirement
for not sending duplicate, conflicting attribute values.  We already
have a SHOULD-level requirement on servers, which hopefully explains
to folks who read the spec why order dependence is a bad idea.

As for the level of conformance requirement for the de facto / ad-hoc
ordering, a SHOULD-level requirement on the ordering might be a good
way to resolve this issue given the variety of opinion we've seen on
the list.  I'll write this up and add some more explanatory text to
help using agent implementors understand this requirement.

Thanks,
Adam


> 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
>