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

[Adam Barth <[e-mail]>]

Let me try rephrasing your proposal to make sure I understand it properly:

(4) Require that among cookies with the same name, user agents ought
to present cookies with longer path attributes before cookies with
shorter path attributes.  The spec should not require or recommend
other ordering constraints.

Can you explain why (4) provides a better cost / benefit trade-off
than (1) or (3)?  In particular, what is the advantage of us adopting
(4) over (1) or (3)?

On Tue, Jan 19, 2010 at 2:50 PM, Daniel Stenberg <[e-mail]> wrote:
> 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.

Do you have data about the relative compatibility of (1), (3), and
(4)?  If not, are you willing to generate this data?  It seems like
there is some interoperability / compatibility risk to (4) that would
be mitigated in (3) and (1).  Without a way to quantify this risk, we
are flying blind.

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

That's right.  Browser vendors are reticent in introduce compatibility
problems with web sites.  That's why we need to be careful about these
issues.  Whether we think that's a good idea on there part, if
shouldn't ignore them if we want them to care about our spec.

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

Quirk is a very judgmental term.  I'd rather talk about behaviors.  In
particular, this sorting behavior seems harmless to me, whereas not
sorting appears risky in the absence of data.

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

Why introduce interoperability problems where none exist?  If the most
widely used user agents are already doing something sensible, it seems
like the path of least resistance is to adopt that behavior.  I'd
rather save my effort for trying to change things that matter.

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

I'm sure there's a site somewhere that depends on the consensus ordering.

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

A common case is that a server will send two Set-Cookie headers in the
same HTTP response:

Set-Cookie: foo=bar
Set-Cookie: baz=qux

With sort order (1), the user agent will respond

Cookie: foo=bar; baz=qux

or omit the cookie header entirely.  I can easily imagine server-side
code that would break if presented with "Cookie: baz=qux; foo=bar".

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

The easiest way to work with all servers is to sort the cookies as
proposed in (1).

Adam