What I meant was that a cookie always has a domain value, it is either specified explicitly by a domain attribute in the set-cookie header or implicitly as the hostname that it came from.
A cookie without a domain is a pretty useless thing; it will *never* be sent to anyone. All of the cookie specs are quite specific about what cookies a client is allowed to send to a server and they all require a domain match. No domain --> no match --> never sent. Any other behaviour would be a serious bug. A case (a weak case, IMHO) could be made that the Cookie constructor could allow a null domain value and we require that a domain be provided by calling setDomain() at some point before the Cookie is actually used, but I really don't see the point in this. Marc Saegesser > -----Original Message----- > From: dIon Gillard [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 06, 2002 6:59 PM > To: Jakarta Commons Developers List > Subject: Re: [httpclient] Constructing Cookies with null > domains (again) > > > Marc Saegesser wrote: > > >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. > > > I suppose it depends on what you're calling a cookie. As far as the > response header is concerned, domain is optional, from the RFC: > > Domain=domain > Optional. The Domain attribute specifies the domain > for which the > cookie is valid. An explicitly specified domain must > always start > with a dot. > > As far as the client's concerned, it's a derived value if not > specified > in the header. > > >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. > > > I'll go against that one, and say that since there is an option for > creating a header from an array of Cookies, and we should > allow users to > create the header without specifying the domain (might want > to send the > same cookie to multiple places), then domain in the cookie > constructor > should be able to be null. Domain passed to create cookie > header shouldn't. > > >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. > > > Agreed. Ditto for createCookieHeader. > > >Marc Saegesser > > > -- > dIon Gillard, Multitask Consulting > http://adslgateway.multitask.com.au/developers > > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
