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) > Cool...reading as I type :) Must be going blind.
> > >If the latest Cookie.java breaks when domain, path, or any other attribute >is null, that's a bug. > Definitely. But the place it is breaking is on the compare, which is used for sorting the cookies. Should null always match a domain? Should it always be less than another domain? I need to think this one through. >Perhaps we should add unit tests for processing null domains, paths, etc., >just to document this contract. > Definitely. >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. > Then we should probably codify this assumption, and in the get method for path, if the value is null, return "/". >- Rod > -- 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]>
