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

["Yngve Nysaeter Pettersen" <[e-mail]>]

On Tue, 19 Jan 2010 23:10:48 +0100, Adam Barth <[e-mail]> 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.
> For example, mail.google.com hosts a public instance of Gmail at
> https://mail.google.com/ and corporate instances of Gmail at
> https://mail.google.com/a/example.com/.  These web applications expect
> their own cookies (with the more specific path) to be presented before
> cookies for other web applications (even if the cookies have the same
> names).  In fact, this behavior is required by the original Netscape
> cookie spec.


For reference, Opera's sorting is this way:

  - Cookies with the most specific domain are sent first. that is, The  
host's cookies are first, then the parent domain, then the grandparent,  
and so on
  - For a specific domain the cookies are organized in most specific  
(longest) path being listed first, then the parent path, and so on.
  - For a specific path it is oldest cookie first.

IMO the cookie with the more specific domain should be sent first, since  
it will have been set by a server that is closer to the receiving server,  
if it wasn't the one setting the cookie.

Our way of selecting and sending cookies follows naturally from how the  
cookie database is organized: As a Tree.

Regarding the specification, I would suggest that it continues to specify  
ordering, at least for path.

AFAIK it will not be possible to define an inter-operable domain ordering  
specification, so instead the specfication should say that servers must  
not rely on a specific ordering for cookies with the same name set for  
different domains and the same path (The path specification means that it  
is perhaps possible to rely on it for same name cookies with different  
name, even for different domains).

Short of using RFC2965 cookies it is not possible to discover the domains  
or paths for two cookies with the same name (unless it is coded in the  
value)

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************