Subject: [http-state] Updated draft

From: Adam Barth <[email-masked]>
Date: Sat, 15 Aug 2009 10:08:57 -0700

I've re-organized the draft to separate the conformance requirements
for servers from the conformance requirements for user agents.  I've
uploaded the new draft as an I-D:

http://www.ietf.org/id/draft-abarth-cookie-01.txt

As always, comment appreciated.

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 15 Aug 2009 23:06:01 +0200 (CEST)

> As always, comment appreciated.

A few comments:

Section 2 "Terminology" describes how the domain matchin is made. I know this 
was like this in RFC2965 as well, but I find it to be a weird placement for 
that description. That's not terminology, it's rather text meant for section 
6.4 in my opinion.

In section 6.3 I found this text:

"The user agent MUST evict a cookie ... if ... More than 50 cookies exist in 
the cookie store with the same domain field."

Is that really a MUST? There's no fixed 50 cookies limit in curl at least and 
I would be surprised if all other HTTP clients would agree on this. May I 
suggest that to be written a MAY instead?

In section 6.4 there's a typo:

    When the user agent generates an HTTP request for a particular URI,
    the user agent SHOULD attach exactly one HTTP named Cookie if the

insert 'header' after HTTP.

I don't understand the section saying:

    When generating a cookie-string from a URI with a "secure" scheme,
    the user agent MUST set the SECURE flag to true.  Otherwise, the user
    agent MUST set the SECURE flag to false.

What 'flag' is this referring to? This section is for sending the Cookie: 
header and I would presume stored received cookies already are marked secure 
or not. Similar wording is used later but then speaks of "the HTTP flag".

The section about the sorting of the cookie-list. Do implementations really 
bother about in which order the cookies are matched? I don't see how that is 
important (and again, I know an implementation that doesn't care).

The text about "Update the last-access field of each cookie" is certainly not 
a MUST but could be a useful suggestion. Still I think it could be left out 
entirely.

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Sat, 15 Aug 2009 16:42:36 -0700

On Sat, Aug 15, 2009 at 2:06 PM, Daniel Stenberg<[email-masked]> wrote:
> Section 2 "Terminology" describes how the domain matchin is made. I know
> this was like this in RFC2965 as well, but I find it to be a weird placement
> for that description. That's not terminology, it's rather text meant for
> section 6.4 in my opinion.

Yes.  I've added a TODO to move this to one of the conformance sections.

> Is that really a MUST? There's no fixed 50 cookies limit in curl at least
> and I would be surprised if all other HTTP clients would agree on this. May
> I suggest that to be written a MAY instead?

Done.  I have it on good authority that there exist sites that break
if you change this number.  However, I've softened the draft to make
50 only a suggestion.

> insert 'header' after HTTP.

Fixed.

> or not. Similar wording is used later but then speaks of "the HTTP flag".

Yeah, this is pretty clumsy.  I was trying to make the cooke selection
algorithm simpler, but it didn't work out well.  I've added a TODO to
fix this.

> important (and again, I know an implementation that doesn't care).

Yes.  The bit about sorting by path length is definitely required for
compatibility.  I remember reading some old bug reports about that.  I
suspect the bit about creation date is important too, although I don't
have concrete examples of sites that break.  I don't have a test case
written for the sorting yet, but I believe IE, Firefox, and Chrome do
this.  I haven't tested Safari or Opera.

> The text about "Update the last-access field of each cookie" is certainly
> not a MUST but could be a useful suggestion. Still I think it could be left
> out entirely.

That's the only text that gives semantics to the last-access field,
which is needed during eviction.

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Sun, 16 Aug 2009 14:45:00 +0200 (CEST)

On Sat, 15 Aug 2009, Adam Barth wrote:

>> bother about in which order
>
> suspect the bit about creation date is important too, although I don't have 
> concrete examples of sites that break.

Hm, ok. It would be very interesting if you can come up with real-world cases 
where this is actually enforced/checked since curl doesn't do any sorting of 
this kind and I would be surprised if all other cookie implementations do.

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Sun, 16 Aug 2009 10:32:20 -0700

On Sun, Aug 16, 2009 at 5:45 AM, Daniel Stenberg<[email-masked]> wrote:
> Hm, ok. It would be very interesting if you can come up with real-world
> cases where this is actually enforced/checked since curl doesn't do any
> sorting of this kind and I would be surprised if all other cookie
> implementations do.

I've added tests for both these behaviors to the test suite.  Here's
how the five most popular browser behave:

Sort first based on path length:
* IE
* Firefox
* Safari
* Chrome
* Opera

Sort second on creation time:
* IE
* Firefox
* Chrome
* Opera

Sort second based on cookie name:
* Safari

Based on this data, it seems reasonable to spec "sort first on path
length and sort second on creation time."  I don't think we'd want to
spec any other ordering, and I don't see the benefit of not specing
the ordering in the user agent conformance section.

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Sun, 16 Aug 2009 20:10:34 +0200 (CEST)

On Sun, 16 Aug 2009, Adam Barth wrote:

> I've added tests for both these behaviors to the test suite.  Here's how the 
> five most popular browser behave:

...

> Based on this data, it seems reasonable to spec "sort first on path length 
> and sort second on creation time."  I don't think we'd want to spec any 
> other ordering, and I don't see the benefit of not specing the ordering in 
> the user agent conformance section.

I beg to differ.

First, this sorting was not in the Netscape cookie spec but is only found in 
RFC2109 and RFC2965.

Then, since clearly user agents that don't do any sorting of the cookies can 
play fine against the vast majority of all sites this seems like a client-side 
invention that have no particular meaning to existing servers. So by 
specifying the sort order you not only make a lot of client code 
"non-compliant" all of a sudden, I think you're also over-specifying something 
that doesn't need to be specified.

As far as I can understand, it could only really have a meaning if more than 
50 (or so) cookies are stored for a domain as then the sort order would decide 
which cookies to discard (or rather not include in the Cookie: header). But 
that won't have to imply that the 50 cookies that ARE sent have to be sent in 
this sorted order.

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Sun, 16 Aug 2009 11:31:50 -0700

> I beg to differ.

Which sorting requirement do you find problematic?  Let's consider the
path-length sorting first.

> First, this sorting was not in the Netscape cookie spec but is only found in

I don't think that should be a factor in our decisions.  Our first
consideration should be the behavior of existing implementations (both
client and server).

> play fine against the vast majority of all sites

User agents comprising >99% of the market share implement path-length
sorting.  The only implementation I'm aware of that does not perform
path-length sorting is CURL.  Are there other implementations we
should factor into our decisions?

I suspect that Internet Explorer, Firefox, Safari, Chrome, and Opera
have collectively been tested on more web sites than CURL.  When 5 out
of 5 major browsers agree, there's likely a reason.

> this seems like a
> client-side invention that have no particular meaning to existing servers.
> So by specifying the sort order you not only make a lot of client code
> "non-compliant" all of a sudden,

I don't think it matters how much code we make non-compliant.  We
should weigh the importance of implementations by market share.  In
this case, we have >99% of the market share in favor of path-length
sorting.

> I think you're also over-specifying
> something that doesn't need to be specified.

Here's the test I think we should use when deciding whether to add a
user agent conformance requirement:

"If I were going to implement a new user agent today and I wanted to
maximize compatibility, would I implement this requirement?"

In this case, it's clear that I would want to implement a behavior
that matches all of the major browsers.

> 50 (or so) cookies are stored for a domain as then the sort order would
> decide which cookies to discard (or rather not include in the Cookie:
> header). But that won't have to imply that the 50 cookies that ARE sent have
> to be sent in this sorted order.

This is not the case.  The priority order for evicting cookies is
different from the order in which cookies appear in the Cookie header
(which is what we're discussing).  You can see that the tests cases
we're using to probe this behavior involve only two cookies each:

0015
0016
path0001
path0002
path0003
path0004

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Sun, 16 Aug 2009 22:42:22 +0200 (CEST)

On Sun, 16 Aug 2009, Adam Barth wrote:

> path-length sorting is CURL.  Are there other implementations we should 
> factor into our decisions?

Right, but did you check libsoup, wget or whatever other fairly common 
non-browser http clients there are out there? Or why not the most popular 
native libs for Java, Python or perl?

As curl is not a browser at all you could test 100% of the browsers and curl 
would still not be in that lump. You cannot use browser share among end users 
as a proper measurement here. If you can reach 99% of the server 
implementations it would matter a lot more.

> I suspect that Internet Explorer, Firefox, Safari, Chrome, and Opera have 
> collectively been tested on more web sites than CURL.  When 5 out of 5 major 
> browsers agree, there's likely a reason.

Then please tell me the reason. Why do they sort the cookies like this? (And I 
don't count "because RFC2109/2965 says so" to be a good explanation.)

And the reversed: how come (virtually) no server-side receivers care about the 
order?

> In this case, it's clear that I would want to implement a behavior that 
> matches all of the major browsers.

I think you're looking at it from the wrong perspective. If I were to 
implement a new cookie "engine" today and maximize compatibility, I would make 
sure that it plays with 99.[something] of the _server_-implementions. And 
funnily enough, I claim that curl does!

A request-header should be looked for compliance in the server-end, imo.

Obviously I don't have any measured numbers to back this up but curl has 
always been used a lot to mimic browsers and to automate what people otherwise 
do manually with browsers, and I've always put in an effort to make sure that 
curl can do everything the browsers can (HTTP wise). This sorting thing has 
never been an issue to my knowledge (and yes I do realize I'm sticking my neck 
out here).

>> it could only really have a meaning if more than 50 (or so) cookies are 
>> stored for a domain as then the sort order would decide which cookies to 
>> discard
>
> This is not the case.  The priority order for evicting cookies is different 
> from the order in which cookies appear in the Cookie header (which is what 
> we're discussing).

Ah, that's what I get for reading it sloppy, sorry.

But it only makes my point even stronger: Why do we specify the order at all? 
What's the useful purpose to any party involved?

-- 

  / daniel.haxx.se

---

From: Dan Winship <[email-masked]>
Date: Sun, 16 Aug 2009 19:19:51 -0400

On 08/16/2009 04:42 PM, Daniel Stenberg wrote:
> As curl is not a browser at all you could test 100% of the browsers and
> curl would still not be in that lump. You cannot use browser share among
> end users as a proper measurement here. If you can reach 99% of the
> server implementations it would matter a lot more.

We cannot reach 99% of server implementations though; many of them are
behind firewalls, or only exhibit the behaviors of interest when you
have an account on them, etc, etc.

What we *can* do is leverage the fact that (a) the implementors of those
servers probably tested their site against IE, and maybe against Firefox
too, and (b) eventually the users of the browsers that they *didn't*
test against will file bugs against those browsers, complaining that
site X doesn't work correctly, and the browser vendor may eventually be
able to figure out why and do something about it, and so we should
expect that more-popular browsers will be more interoperable, since
they'll have received more bug reports about lame sites.

> Then please tell me the reason. Why do they sort the cookies like this?
> (And I don't count "because RFC2109/2965 says so" to be a good
> explanation.)

They sort the cookies like that because IE6 sorted the cookies like
that. And IE6 didn't have any reason at all; the cookies had to come out
in some order, and this happens to be the order they came out in.

> And the reversed: how come (virtually) no server-side receivers care
> about the order?

Because most web developers aren't complete morons. Unfortunately, some
of them *are* complete morons, and write code that blindly assumes that
username will always be $cookies[0] and shopping_cart_contents will
always be $cookies[1], etc. If you read through the Firefox cookie
source, there are comments in the cookie-ordering code with links to
some old bugs pointing out some specific web sites, but the bugs in
question are several years old and the specific web sites they mention
might no longer demonstrate the bugs. OTOH, since Firefox now sorts the
same way IE does, that means that even if the moron web developer tests
his site against both IE and Firefox, it works in both now, and so he
doesn't realize he's a moron.

> implement a new cookie "engine" today and maximize compatibility, I
> would make sure that it plays with 99.[something] of the
> _server_-implementions. And funnily enough, I claim that curl does!

curl *does* work with 99.[something]% of web sites. But
(100 - 99.[something]) * number_of_web_sites_in_the_world is still a big
number.

-- Dan

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 17 Aug 2009 09:37:58 +0200 (CEST)

On Sun, 16 Aug 2009, Dan Winship wrote:

> curl *does* work with 99.[something]% of web sites. But (100 - 
> 99.[something]) * number_of_web_sites_in_the_world is still a big number.

Yes, but similar to how the cookie definition covers what we estimate to be 
99.6% of the cookie sites (for the 'expires' date format), we would cover a 
similar percentage of sites by not specifying the sort order.

You both are claiming that only because the major browsers do something for 
0.[something]% of the servers we need to have it specified while I would argue 
that it is enough for the spec to cover 99.[something]%.

If sites depend on the exact sort order of one of these browsers, they could 
also easily break because the subtle differences in sort order they use so 
thus none of the browsers could claim to be 100% covering since they differ in 
implementations.

But sure, let's leave this for now. I still won't agree that sort order should 
be defined until someone can come up with a good reason why it is there in the 
first place, or can present at least a small amount of actual server side 
users that break if this sorting isn't done.

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Mon, 17 Aug 2009 08:53:59 -0700

> similar percentage of sites by not specifying the sort order.

The difference is specifying a robust date parser is very difficult
whereas specifying the sort order for the Cookie header is quite
simple.

> 0.[something]% of the servers we need to have it specified while I would
> argue that it is enough for the spec to cover 99.[something]%.

Although 99% sounds like good coverage, we should keep in mind that
the 101rst most popular site (according to Alexa) is tagged.com, which
Alexa describes as "one of the top social networking sites in the
world."  In reality, browsers must be compatible with much more than
99% of we sites.

In fact, I think we should aim for 99.999% compatibility.  Although, I
would be happy if we're actually able to achieve 99.99%.  If you run
the numbers for a reasonable amount of daily browser usage, you can
actually use the browser for a reasonable amount of time before you
run into compatibility issues at that level.

> thus none of the browsers could claim to be 100% covering since they differ
> in implementations.

You're exactly right that servers are extremely fragile, especially
with regards to the cookie header.  However, they won't break due to
variations in sort order issues because all the major browsers use the
same sort order!

> But sure, let's leave this for now. I still won't agree that sort order
> should be defined until someone can come up with a good reason why it is
> there in the first place, or can present at least a small amount of actual
> server side users that break if this sorting isn't done.

There's a clear cost to not specifying the sort order: new
implementations that follow the spec will behave differently than all
the major browsers.  However, you haven't articulated a reason why we
ought not to specify the sort order.

Adam

---

From: Adam Barth <[email-masked]>
Date: Mon, 17 Aug 2009 09:08:12 -0700

> ought not to specify the sort order.

Put another way, if you were writing a new cookie implementation
today, why would you want to use any other sort order?  In the end,
you have to pick an ordering.  You might as well pick the one that's
used by 99% of the market.  Instead of forcing new implementations to
reverse engineer this information, we should just say.

Adam

---

From: Bil Corry <[email-masked]>
Date: Mon, 17 Aug 2009 11:34:43 -0500

> if you change this number.  However, I've softened the draft to make

A bit dated, Nicholas Zakas of Yahoo! talks about the maximum number of cookies[1]:

---8<---
    * Microsoft indicated that Internet Explorer 8 increased the cookie limit per domain to 50 cookies but I’ve found that IE7 also allows 50 cookies per domain. Granted, this may have been increased with a system patch rather than having the browser’s first version ship like this, but it’s still more than the 20 that was commonly understood to be the limit.
    * Firefox has a per-domain cookie limit of 50 cookies.
    * Opera has a per-domain cookie limit of 30 cookies.
    * Safari/WebKit is the most interesting of all as it appears to have no perceivable limit through Safari 3.1. I tested setting up to 10,000 cookies and all of them were set and sent along in the Cookie header. The problem is that the header size exceeded the limit that the server could process, so an error occurred.
--->8---

He also mentions differences in cookie eviction:

---8<---
   1. The least recently used (LRU) approach automatically kicks out the oldest cookie when the cookie limit has been reached in order to allow the newest cookie some space. Internet Explorer and Opera use this approach.
   2. Firefox does something strange: it seems to randomly decide which cookies to keep although the last cookie set is always kept. There doesn’t seem to be any scheme it’s following at all. The takeaway? Don’t go above the cookie limit in Firefox.
--->8---

And differences in cookie size support (although this conflicts with results Daniel Stenberg posted earlier[2]):

---8<---
    * Firefox and Safari allow cookies with up to 4097 characters, that’s 4096 for the name and value and one for the equals sign.
    * Opera allows cookies with up to 4096 characters, which is for the name, value, and equals sign.
    * Internet Explorer allows cookies with up to 4095 characters, which is for the name, value and, equals sign.
--->8---

- Bil

[1] http://www.nczonline.net/blog/2008/05/17/browser-cookie-restrictions/
[2] http://www.ietf.org/mail-archive/web/http-state/current/msg00115.html

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 17 Aug 2009 19:40:16 +0200 (CEST)

On Mon, 17 Aug 2009, Adam Barth wrote:

> You're exactly right that servers are extremely fragile, especially with 
> regards to the cookie header.  However, they won't break due to variations 
> in sort order issues because all the major browsers use the same sort order!

If the path names aren't of identical lengths, yes. But Safari does it 
differently if they are - if I understood your mail correctly. And lots of 
cookies are bound to have the same path lengths.

> There's a clear cost to not specifying the sort order: new implementations 
> that follow the spec will behave differently than all the major browsers. 
> However, you haven't articulated a reason why we ought not to specify the 
> sort order.

My reason is quite simply because lots of existing "cookie clients" and 
"cookie servers" have no sorting at all. By saying sorting is necessary for 
cookie compliance, lots of client implementations are thus effectively made 
broken.

This for an effect very few sites care about to the extent that I wasn't even 
aware of it until just a few days ago. I would MUCH rather that we claim those 
few rare server sides non-compliant. We would then have a section explaining 
that some broken sites would in the past depend on this sorted behavior that 
no spec ever mandated.

I would claim that the share of HTTP clients that don't sort (this way) is 
larger than the share of HTTP sites that insist on cookies being sorted. But I 
don't have any numbers to back this up.

But I'll drop this subject for now.

-- 

  / daniel.haxx.se

---

From: Julian Reschke <[email-masked]>
Date: Mon, 17 Aug 2009 19:43:58 +0200

> reverse engineer this information, we should just say.

Why would you have to pick an ordering?

In Java, I might just drop then into a HashSet, and never worry about 
ordering...

BR, Julian

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 17 Aug 2009 19:51:13 +0200 (CEST)

> Daniel Stenberg posted earlier[2]):

Hm, well my tests should be perfectly repeatable and as I posted my code for 
the tests you can review it and see for yourself (or re-implement them using 
something else). I couldn't find any specific details on how mr Zakas got his 
numbers.

-- 

  / daniel.haxx.se

---

From: Bil Corry <[email-masked]>
Date: Mon, 17 Aug 2009 12:55:53 -0500

Daniel Stenberg wrote on 8/17/2009 12:51 PM: 
>> And differences in cookie size support (although this conflicts with
>> results Daniel Stenberg posted earlier[2]):
> 
> Hm, well my tests should be perfectly repeatable and as I posted my code
> for the tests you can review it and see for yourself (or re-implement
> them using something else). I couldn't find any specific details on how
> mr Zakas got his numbers.

Yes, I saw it as a warning that everything Nicholas Zakas posted should be independently confirmed.

- Bil

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 17 Aug 2009 19:57:15 +0200 (CEST)

On Mon, 17 Aug 2009, Daniel Stenberg wrote:

> something else). I couldn't find any specific details on how mr Zakas got 
> his numbers.

Oh, his numbers is for the whole "NAME=VAR" construct while my tests only 
evaluated the max lenth of NAME. Could explain a bit.

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Mon, 17 Aug 2009 11:50:37 -0700

> cookie compliance, lots of client implementations are thus effectively made

I don't see why that matters.  I can sit in my basement and write 1000
cookie implementations that no one uses and it doesn't matter whether
we declare them non-compliant.

> This for an effect very few sites care about to the extent that I wasn't
> even aware of it until just a few days ago. I would MUCH rather that we
> claim those few rare server sides non-compliant. We would then have a
> section explaining that some broken sites would in the past depend on this
> sorted behavior that no spec ever mandated.

These site are non-complaint.  We're discussing the user agent
conformance section.  User agents need to know how to deal with broken
sites in an interoperable manner.

If you like, we can add a requirement to the server conformance
section admonishing servers not to depend on this behavior.

> larger than the share of HTTP sites that insist on cookies being sorted. But
> I don't have any numbers to back this up.

Comparing those quantities is irrelevant.

> But I'll drop this subject for now.

Ok.

Adam

---

From: Adam Barth <[email-masked]>
Date: Mon, 17 Aug 2009 11:52:41 -0700

> In Java, I might just drop then into a HashSet, and never worry about

In the end you have to serialize the set of cookies you transmit to
the server into a sequence of bytes for the Cookie header.  When you
do this, you have to pick an ordering for that sequence of bytes.  Of
course, you can pick a different order each time you serialize, but
that seems inferior to matching the behavior of 99% of the market.

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 17 Aug 2009 21:43:37 +0200 (CEST)

> evaluated the max lenth of NAME. Could explain a bit.

I'm obviously mixing up my own tests. The tests we were talking about checked 
the VAR length as per above. My tests for the NAME length have not been 
completed.

-- 

  / daniel.haxx.se

---

From: Julian Reschke <[email-masked]>
Date: Mon, 17 Aug 2009 21:45:32 +0200

> that seems inferior to matching the behavior of 99% of the market.

Well, no. I'll just obtain an Iterator from Java, and the order it 
returns the values will be implementation-dependant.

BR, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Mon, 17 Aug 2009 21:48:47 +0200

> returns the values will be implementation-dependant.

Well in that case you'll have to use some other strategy of implementing  
this if you want to be compatible.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 17 Aug 2009 21:51:41 +0200

Anne van Kesteren wrote:
> On Mon, 17 Aug 2009 21:45:32 +0200, Julian Reschke 
> <[email-masked]> wrote:

Anne, I do understand that. I was merely replying to the claim that at 
some point every implementation needs to "decide how to sort". That's 
simply not true; an implementation could decide not to care, and let 
some default apply.

BR, Julian

---

From: Adam Barth <[email-masked]>
Date: Mon, 17 Aug 2009 13:25:00 -0700

On Mon, Aug 17, 2009 at 12:51 PM, Julian Reschke<[email-masked]> wrote:
> Anne, I do understand that. I was merely replying to the claim that at some
> point every implementation needs to "decide how to sort". That's simply not
> true; an implementation could decide not to care, and let some default
> apply.

Which, itself, would be a decision (and likely a poor decision).

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 17 Aug 2009 23:19:27 +0200 (CEST)

> Which, itself, would be a decision (and likely a poor decision).

If there's nothing in the spec that says which order to use, why waste more 
bytes than necessary on the job?

That's probably the reason why several implementations don't sort today: the 
cookies just happens to be kept around in memory in a particular order, and 
that order is then used in the Cookie: header. Or it is sorted based on some 
other metric.

I've browsed the Cookie: code for curl, wget, libsoup, pavuk, lftp and aria2. 
If I didn't miss anything, none of these cookie implementations sort the 
cookies as the browsers.

-- 

  / daniel.haxx.se

---

From: Dan Winship <[email-masked]>
Date: Mon, 17 Aug 2009 19:15:54 -0400

On 08/17/2009 05:19 PM, Daniel Stenberg wrote:
> I've browsed the Cookie: code for curl, wget, libsoup, pavuk, lftp and
> aria2. If I didn't miss anything, none of these cookie implementations
> sort the cookies as the browsers.

You missed this in soup-cookie-jar.c:

	/* FIXME: sort? */

Adam's explanation of cookie sorting is *exactly* the sort of
information I was hoping to get out of this group. Our goal (as I
understand it) is to document the facts of cookies in the real world.
It's a fact that all major browsers sort cookies the same way. It's a
fact that some web sites depend on this. So we document it, and I get to
remove a FIXME, and WebKitGtk works with a few more sites than it used to.

Be liberal in what you accept (clients MUST accept all date formats,
servers MUST accept cookies in any order) and conservative in what you
send (clients MUST send cookies in the recommended order, servers MUST
send dates in the recommended format).

-- Dan

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 18 Aug 2009 08:51:25 +0200

> send dates in the recommended format).

+1

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 18 Aug 2009 09:13:58 +0200 (CEST)

> You missed this in soup-cookie-jar.c:

Actually I didn't. It instead convinced me that libsoup doesn't sort which was 
what I was curious about (and you hadn't mentioned). So I could in no time 
whip up six (6!) HTTP clients that support cookies that don't sort them in the 
Cookie: header. I think taken together they do represent a fair amount of 
current usage.

FIXMEs or TODOs can be fixed in future releases for most software, that 
doesn't really change what is in use today, right now.

> Be liberal in what you accept (clients MUST accept all date formats, servers 
> MUST accept cookies in any order) and conservative in what you send (clients 
> MUST send cookies in the recommended order, servers MUST send dates in the 
> recommended format).

I think that servers MUST accept them in any order, but clients only SHOULD 
send them sorted like that (path len first then creation date).

Uhm, come to think of it on the matter of creation dates: the older 
Firefox/Mozilla/Netscape cookie file format doesn't save the creation dates of 
cookies, only expiration dates. So surely they won't be able to send cookies 
in the correct order after a restart?

-- 

  / daniel.haxx.se