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 Mon, 18 Feb 2002 03:34:58 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)
>
>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:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message