On Tue, 26 Feb 2002, Daniel Stenberg wrote:

[yaya, I'm replying to myself]

> Let's call this problem A.

The other two problems are dealt with separately. Problem B seems to be
addressed with my posted fix, and I can't repeat problem C on my test
machines.

> I think we might have a cookie recording problem here. If we first receive
> a cookie named NAME for domain 'loonie.domain.boo' and then later receive
> another cookie line with NAME for domain 'domain.boo' (cutting off parts of
> the previous domain) this second cookie will be stored as a different one
> due to the different domain property. But I figure they should actually be
> treated as the same. (Cookies are a tricky business due to the lack of
> standards, or rather due to the lack of sites following the actual
> standards.)

I think we need to (get some help to) fire up a browser here on a test site
to see how they behave and clone their behavior.

I've had a look in the cookie documents. The original Netscape document just
isn't detailed enough to mention how this is supposed to be done. The most
recent cookie RFC, the RFC2965 (that obsoletes the RFC2109) actually says
that curl's current way is the right way to deal with Set-Cookie2 headers
(not that curl deals with those exact headers, but as I said, no one follows
these standards they're ignored by a whole industry).

A little quote from section 3.3.3 seems appropriate:

   If a user agent receives a Set-Cookie2
   response header whose NAME is the same as that of a cookie it has
   previously stored, the new cookie supersedes the old when: the old
   and new Domain attribute values compare equal, using a case-
   insensitive string-compare; and, the old and new Path attribute
   values string-compare equal (case-sensitive).

curl doesn't do the path check case-sensitive, but otherwise it follows this
approach.

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/