commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dIon Gillard <>
Subject Re: [httpclient] New change to breaks Cactus
Date Sun, 17 Feb 2002 22:32:48 GMT
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 
>>> 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.
Cool...reading as I type :) Must be going blind.

>If the latest 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.

>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

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message