I've spent a fair amount of time recently reading and re-reading RFC 2109 and the Netscape cookie spec-like-thing. Here's my current understanding.
All cookies have a domain. A domain is required in order to determine which cookies should be sent with a given request. A cookie's domain can come from two different places: 1) a domain attribute in the set-cookie header or 2) default to the host that sent the cookie. There are two ways that cookies get created in HttpClient, by calling a Cookie constructor or by parsing a set-cookie header. Both the constructors and parse take a value for the domain. So the question is what is the meaning of this domain value and what are the legal values. For the constructors, the case is fairly straight-forward. The constructor has no knowledge of the request, response or any headers, it simply creates the cookie with the given values. Since, as I claim above, all cookies must have a domain, allowing a null domain value to the constructor creates a cookie that isn't valid. Thus, the constructors should throw an IllegalArgumentException for null domains. The parse() method has access to the set-cookie header, but not the request or response. The domain parameter passed to parse() should be interpretted as the default domain for the cookie in case the set-cookie header doesn't contain a domain attribute. Since domain attributes are not required, and all cookies must have a domain, the domain passed to parse() should not null and the method should throw an IllegalArgumentException for null domains. Marc Saegesser > -----Original Message----- > From: Waldhoff, Rodney [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 05, 2002 7:06 AM > To: 'Jakarta Commons Developers List ' > Subject: RE: [httpclient] Constructing Cookies with null > domains (again) > > > I think both Marc and dIon raise some good points. The spec > clearly allows > domain to be null in a Set-Cookie header, but also speaks to > what clients > should assume to be the domain in that circumstance. > > So what is a *.httpclient.Cookie, really? A representation > of the somewhate > abstract "client side state"? A container for the parsed > attributes of a > Set-Cookie header? A container for the attributes that go > into a Cookie > header? Some combination of these? > > Under what circumstances would we want it to have a null > domain or path? Is > it ever useful to know, for example, that the server didn't indicate a > domain, but the client "assumed" one? (And assuming it is > useful, is Cookie > the right place to go to find out, or is that really a question about > Headers?) Is it always possible, in practice, to provide a > default based > upon the context in which the Cookie/Set-Cookie headers are > encountered? > > (I'm really not trying to be coy, I honestly don't know the > answers here.) > > - Rod > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
