Well -- I wish I had some good news (such as "I recreated this easily!") ...
But I don't.

The behavior is consistant when reading cookies back from an SSL post to an
AOL server running Netscape-Enterprise/4.1. I haven't been able to re-create
the problems when running on my Apache/PHP setup.

Maybe this is a false alarm ... Or perhaps something so obscure that it's
not likely to be a problem for anyone else.

At any rate, the app I'm building needs to deal with the inconsistencies I'm
seeing in this particular environment, and doesn't need to be portable ...
So, I guess I'll start hacking away.

My apologies -- I wish I were able to re-create the problem, but
copying/pasting the headers I got back from AOL's SSL server and running
them through my Apache/PHP setup generated no problems whatsoever.

As I continue on with this project, I'll keep the list posted if I come
across anything that clarifies these issues further.

Thanks,
Clay

___________________________
Clay Loveless
Webmaster, Crawlspace
http://www.crawlspace.com/

> From: Daniel Stenberg <daniel_at_haxx.se>
> Reply-To: curl_at_contactor.se
> Date: Tue, 26 Feb 2002 15:24:33 +0100 (MET)
> To: Curl Mailinglist <curl_at_contactor.se>
> Subject: Re: Bugs with cookies
>
> 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/
>
Received on 2002-02-26