> -----Original Message-----
> From: Waldhoff, Rodney [mailto:[EMAIL PROTECTED]]
> Sent: 17 February 2002 18:43
> To: 'Jakarta Commons Developers List '
> Subject: RE: [httpclient] New change to Cookie.java breaks Cactus
>
> >>My analysis is that the previous Cookie class
> >>was more lenient WRT the cookie domain
> >>(i.e. it could be "null"). However it seems the new
> >>Cookie.compare() method throws a NPE if it is null.
> >>
> >>Questions :
> >>1/ Is this done voluntarily (i.e. force the user
> >>to always specify a
> >>domain) ?
>
> > Not particularly, but it does make
> > some sense. I can't find anywhere in
> > the RFC that says Domain is optional.
>
> I can. See section 4.2.2 of RFC 2109.
> (http://www.w3.org/Protocols/rfc2109/rfc2109.txt)
>
> If the latest Cookie.java breaks when domain, path, or any other
attribute
> is null, that's a bug.
>
I also think so. As I said in a previous email, the real problem was not
with domain (that are always specified in Cactus) but rather with the
"path" which is set to null in most cases. However, it is the same issue
and I agree we should allow nulls as is the case in other places in
Cookie.java. It seems it is only the newly added Cookie.compare() that
breaks this behaviour.
> Perhaps we should add unit tests for processing null domains, paths,
etc.,
> just to document this contract.
>
exactly my thoughts (see my previous email) ! :-)
> The typical browser behavior, which I think is specified by the old
> "netscape" cookie spec, is to assume a default path of "/" and a
default
> domain of the full-specified domain used in the request. I'm pretty
sure
> that's the behavior Cookie used to have.
>
> - Rod
Thanks Rod.
-Vincent
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
