> 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?
I don't see it specified one way or the other in the javadoc, but it looks like currently none of the parse methods will accept null for domain or path. The domain and path attributes of the parse methods are the domain/path of the request that obtained the set-cookie response (for cookie-acceptence purposes), which in the general case is not the same as the domain/path attributes of the set-cookie header being parsed, so there are at least two different questions here. I don't have a strong opinion as to whether or not the parse(...) methods should allow null host or path arguments. I do think that Cookie.setDomain and Cookie.setPath should allow null values, and when the corresponding member is null, getDomain and getPath should return null. (Note that currently setDomain doesn't allow null, although probably not by design.) Defaults values, like "/" for null paths should be determined by the response-reading parser or the request-writer writer, not by the Cookie struct itself, IMO. - Rod > dIon Gillard PS: Both Cookie.parse() and Cookie.setDomain() point to the risk of some of the recent javadoc and parameter-validation patches. The current behavior may be circumstantial rather than intentional, and we don't want to turn coincidental behaviours into contracts without thinking thru what those contracts should be.