Waldhoff, Rodney wrote: >>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. > Yep, and I think that this would be ok for us to codify. I'm happy that the args to parse for domain and path shouldn't be null, as they should come from the request.
>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. > Cool. I'm happy that domain and path being null as properties of cookie is a valid thing. The code should be fixed to allow it, and I think I've got most cases fixed now. >- 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. > 100% agreed, hence the discussions up here before changes. I think the discussion is the important bit, the code changes themselves are fairly inconsequential. The other thing that came up is that the circumstantial behaviours are seen as contracts, as Vincent picked up fairly quickly that we'd introduced an incompatibility, and that we were lacking some tests :) -- dIon -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
