Re: [http-state] Ticket 5: Cookie ordering

[David Morris <[e-mail]>]

On Tue, 19 Jan 2010, Adam Barth wrote:

> On Tue, Jan 19, 2010 at 8:51 PM, David Morris <[e-mail]> wrote:
>> On Tue, 19 Jan 2010, Adam Barth wrote:
>>> Ticket 3 is still open for discussion, but I'd like to get started
>>> talking the next ticket:
>>> http://trac.tools.ietf.org/wg/httpstate/trac/ticket/5
>>>
>>> == Overview ==
>>>
>>> Currently the draft defines the order in which cookies should appear
>>> in the Cookie header.  In particular, cookies are ordered first by the
>>> length of the Path attribute (longest first) and then by creation date
>>> (earliest first).  The majority of the most widely used user agents
>>> use this ordering. (I can look up exactly which browsers follow the
>>> ordering if that's important.)
>>>
>>> Sending cookies with longer (i.e., more specific) paths first is
>>> important for compatibly because some servers host multiple (mutually
>>> trusting) web applications at different (possibly overlapping) paths.
>>
>> I think 'longer' is not a precise term ... likewise, 'more specific' isn't
>> precise enough to avoid confusion. I think what would be expected is that
>> the path sith the most 'levels' (as noted by '/' characters) is longer in a
>> deeper into the hierarachy sense. Same depth, the age rule could apply.
>>
>> If 'more specific' is already defined similar to what I've outlined,
>> you can igore this comment.
>
> In this case, all the cookie paths are prefixes of the Request-URI
> path, so these all amount to the same thing.  FWIW, longer is a
> precise term: literally the one whose path attribute contains more
> characters.

More characters doesn't seem like the right definition, even if it works 
most of the time. If the argument is, as you've made, that the requirement
is for a server to handle cookies in the most precise order ... it will
be related to logical depth of the hierarchy and not character length.