Hey

As I've mentioned before, I'm involved in the IETF http-state working group
which is working to document how cookies are used in the wild today. The idea
is to create a spec that new implementations can follow and that existing
implementations can use to become more interoperable.

(If you're interested in these matters, I can only urge you to join the
http-state mailing list and participate in the discussions.)

The subject of how to order cookies in outgoing HTTP Cookie: headers have been
much debated over the recent months and I've also blogged about it[1]. Now,
the issue has been closed[2] and the decision went quite opposite to my
standpoint and now the spec will say that while the servers SHOULD not rely on
the order (yeah right, some obviously already do and with this speced like
this even more will soon do the same) it will recommend clients to sort the
cookies in a given way that is close to the way current Firefox does it[3].

This has the unfortunate side-effect that to become fully compatible with how
the browsers do cookies, we will need to sort our cookies a bit more than what
we just recently introduced. That in itself really isn't very hard since once
we introduced qsort() it is easy to sort on more/other keys.

The biggest problem we get with this, is that the sorting uses "creation time"
of the cookies. libcurl and curl and others mostly use the netscape cookie
files to store cookies and keep state between invokes, and that file format
doesn't include creation time info! It is a simple text-based file format with
TAB-separated columns and the last (7th) column is the cookie's content.

In order to support the correct sorting between sessions, we need to invent a
way to pass on the creation time. My thinking is that we do this in a way that
allows older libcurls still understand the file but just not see/understand
the creation time, while newer versions will be able to get it. This would be
possible by extending the 'expires' field (the 6th) as it is a numerical value
that the existing code will parse as a number and it will stop at the first
non-digit character. We could easily add a character separation and store the
creation time after. Like:

Old expire time:

  2345678

New expire+creation time:

  2345678/1234567

This format *might* even work with other readers of this file format if they
do similar assumptions on the data, but the truth is that while we picked the
format in the first place to be able to exchange cookies with a well known
and well used browser, no current browser uses that format anymore...

[1] - http://daniel.haxx.se/blog/2010/01/20/cookie-order/

[2] - http://www.ietf.org/mail-archive/web/http-state/current/msg00732.html

[3] - I believe it sorts on path length, domain length and time of creation,
       but as soon as the next draft goes online it will be easy to read the
       exact phrasing. The existing draft exists at:
       http://tools.ietf.org/html/draft-ietf-httpstate-cookie-05

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html