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

[Daniel Stenberg <[e-mail]>]

On Tue, 19 Jan 2010, Adam Barth wrote:

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

My take on cookies is from the other direction. I think we should specify and 
document what needs to be done in order to work with the vast majority of 
sites. I don't think mimicing browsers is a good idea if there's no demand for 
that from the other side.

I know that just about every behavior in browsers can be tracked back to a bug 
in at least one of them and then the others followed or had their own bug 
report and acted independently. Still, many of those acts were more or less 
server-side bugs that SHOULD (imho of course but I suspect I'm not alone in 
this belief) have been fixed in the servers but browser vendors have been too 
scared to loose users so they've instead adapted to stupidities.

But this said, I'm willing to say that a specific "quirk" is no longer a 
server side bug if a large enough amount of servers are already using it. Say 
if three or more of the top-500 sites do it (I'm just throwing out a way to 
count, I didn't really think the numbers through).

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

(This is a change compared to my previous statements in this matter.) I now 
agree that there's in fact a need to be certain that the "most specific" 
version of two names is sent first, and I quite like the phrasing the netscape 
doc:

   cookies with a more specific path mapping should be sent before cookies with
   less specific path mappings

I don't think it needs to say that _all_ cookies need to be sorted on path 
length, as that's not what servers need.

The purpose of the suggested secondary sort key on creation date however is 
less clear to me. That would be for sites using overlapping paths (with the 
same lengths), identical cookie names and then it would depend on which order 
the cookies were created. Is there really a presently existing site that 
requires this functionality in browsers?

> (3) Require that cookies with longer paths appear before cookies with
> shorter paths

If they have the same name, yes.

> but do not require an ordering among cookies with equal path lengths.  This 
> approach maximizes user agent flexibility while meeting the most important 
> compatibility needs, but it's unclear to me that there is value in 
> maximizing user agent flexibility in this regard.  It seems like if we're 
> going to specify an ordering for cookies, we might as well specify the total 
> ordering used by the most popular user agents.

Since user agents can also at whim decide to not accept cookies (and perfectly 
allowed to do so according to previous and this spec), a server cannot 
reliably know in advance which cookie that was created first so it couldn't 
reliably be written to depend on that order. Could it?

Again: alternative implementations do not necessarily seek to act like other 
browsers, they may just try to work against all servers.

-- 

  / daniel.haxx.se