commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dIon Gillard <d...@multitask.com.au>
Subject Re: [httpclient] New change to Cookie.java 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 
>>>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:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message