Marc Saegesser wrote:
>/* I think this should throw IAE, but I can live with it,
> * if people really think this sort of thing is useful.
> */
>cookies[0] = new Cookie(null, "name0", "value0");
>
It's not that we think it's useful - it's being done now, so changing it
breaks people's code.
>/* While this seems valid, I don't like that we can construct
> * a cookie with no path set. Cookies should always have a
> * path (just like a domain) otherwise they are of little use.
> * We'll never be able to send them.
> */
>cookies[1] = new Cookie("fubuar.com", "name1", "value1");
>
See later comments.
>/* This one makes sense */
>cookies[2] = new Cookie("fubar.com", "name2", "value2",
> "/path", null, false)
>
>/* This *must* fail. I'd prefer throwing IAE, but NPE
> * would be OK. The purpose of createCookieHeader is
> * to build a cookie header that contains all the cookies
> * from the given array that match the given domain and
> * path as described in the specification. If you aren't
> * given a domain or a path you can't create the header.
> */
>Cookie.createCookieHeader(null, null, cookies);
>
Agreed. The domain and path methods to create cookie header shouldn't be
null.
>/* If we allow the creation of Cookies without domains
> * or paths, then we *must* prevent them from being sent
> * to a server. Given the three cookies created above,
> * only cookie[2] would be added to the header. The domain
> * for cookie[0] doesn't match (it's null) and the path
> * for cookie[1] doesn't match (it's null).
> */
>Cookie.createCookieHeader("fubar.com", "/path/path", cookies);
>
Null should match *any* path or domain. This is the way match works at
the moment.
>I'll give up on throwing exceptions in the Cookie constructors. People can
>create their own cookies with the domain or path null. I'll fix the Cookie
>class so that it won't barf when it sees these cookies, but they'll never
>
Where does the class fail at the moment? I thought that we'd covered all
the cases in the tests and the only ones failing are the ones for
createCookieHeader. Is there a test case that we've missed?
>show up in any cookie header until someone comes along and calls the
>setDomain() and setPath() methods on them to give them a valid values.
>
Why wouldn't they show up in the header? match picks them up ok at the
moment....
>Marc Saegesser
>
--
dIon Gillard, Multitask Consulting
http://adslgateway.multitask.com.au/developers
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
