I have to concur with Ross on this. It seems that these proposed changes are
the right thing to do.
Peace. -njg
---------- Forwarded Message ----------
Subject: Re: Fwd: cookie domains; curl vs mozilla
Date: Wed, 16 Apr 2003 17:36:49 -0400
From: Ross Patterson <Ross.Patterson_at_CatchFS.Com>
To: Nicholas.Gimbrone_at_CatchFS.Com

From: Daniel Stenberg <daniel_at_haxx.se>
> I've done some experienting with how cookies are treated by Mozilla the
> browser. It all started with me noticing differences in how curl sends back
> cookies compared with how Mozilla behaves. As you might know, cookies is a
> gray area as no one follows any recent standards but instead all just build
> upon their own interepretations of the ancient original netscape document
> for how cookies are supposed to work.

The original "standard" (hah!) is the Netscape definition, currently
available
at http://wp.netscape.com/newsref/std/cookie_spec.html. The description of
DOMAIN= there is:

        When searching the cookie list for valid cookies, a comparison of the domain
        attributes of the cookie is made with the Internet domain name of the host
        from which the URL will be fetched. If there is a tail match, then the
cookie
        will go through path matching to see if it should be sent. "Tail matching"
        means that domain attribute is matched against the tail of the fully
        qualified domain name of the host. A domain attribute of "acme.com" would
        match host names "anvil.acme.com" as well as "shipping.crate.acme.com".

        Only hosts within the specified domain can set a cookie for a domain and
        domains must have at least two (2) or three (3) periods in them to prevent
        domains of the form: ".com", ".edu", and "va.us". Any domain that fails
        within one of the seven special top level domains listed below only require
        two periods. Any other domain requires at least three. The seven special top
        level domains are: "COM", "EDU", "NET", "ORG", "GOV", "MIL", and "INT".

        The default value of domain is the host name of the server which generated
        the cookie response.

The other "standard" is RFC 2965, which says (when describing Set-Cookie2,
the
follow-on to Set-Cookie):

        The value of the Domain attribute specifies the domain
        for which the cookie is valid. If an explicitly specified value
        does not start with a dot, the user agent supplies a leading dot.

> Here's a summary of my findings on what Mozilla does depending on the
> domain contents of the incoming Set-Cookie: header:
>
> 1. Incoming set domain => foobar.com
>
> Mozilla prepends a dot when the domain name is saved in the cookie file,
> and considers this cookie for all host names that end with "foobar.com".

This is correct behavior. Mozilla can store the cookie any way it wants to,
but the result is correct per the "acme.com" example.

> 2. Incoming set domain => .foobar.com
>
> Mozilla saves the name like this in the cookie file, and considers this
> cookie for all host names that end with "foobar.com".

This is correct behavior, implied by the Netscape spec although not expicitly
stated. RFC 2965 explicitly states it, but isn't the spec for the Set-Cookie
header.

> 3. If no domain was set, but we speak with 'www.foobar.com'
>
> Mozilla saves the cookie for domain 'www.foobar.com' and only considers
> the cookie for that particular host.

Correct, per the last paragraph above.

> Does anyone have anything to object or comment on this behavior? I think it
> would make sense to make libcurl work as similar as possible... libcurl
> differs in the first case, where it doesn't prepend any dot, and in the
> third case since libcurl always suffix-check the domain name against the
> host it talks to.

libcurl is wrong in the third case, and a change should be made. In the
first
case, all that matters is whether "domain=acme.com" matches "anvil.acme.com"
and "shipping.crate.acme.com", not the technique used for storage. It sounds
like the change is justified for both cases.

Ross

-- 
Ross A. Patterson
Chief Technology Officer
CatchFIRE Systems, Inc.
5885 Trinity Parkway, Suite 220
Centreville, VA  20120
(703) 563-4164
-------------------------------------------------------
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf