Waldhoff, Rodney wrote: >>>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. > >Perhaps we should add unit tests for processing null domains, paths, etc., >just to document this contract. > >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 > Rod,
how about the parameters passed to parse. From reading of the javadoc, the domain and path passed to parse shouldn't be null. Is this correct? -- dIon Gillard, Multitask Consulting http://www.multitask.com.au/developers -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
