commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Saegesser <Marc.Saeges...@apropos.com>
Subject RE: [httpclient] Constructing Cookies with null domains (again)
Date Thu, 07 Mar 2002 14:44:26 GMT
/* 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");

/* 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");

/* 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);

/* 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);


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
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.  

Marc Saegesser 

> -----Original Message-----
> From: dIon Gillard [mailto:dion@multitask.com.au]
> Sent: Wednesday, March 06, 2002 10:05 PM
> To: Jakarta Commons Developers List
> Subject: Re: [httpclient] Constructing Cookies with null 
> domains (again)
> 
> 
> Marc Saegesser wrote:
> 
> >Well, I don't see your cookie dump, but what your going to 
> see on the server
> >side (since you're running in a servlet) is different than 
> what the client
> >is going to see (which is what HttpClient is).
> >
> >Let me see if I can beat this to death one more time.  
> HttpClient can get
> >cookies in two ways:  1) from a set-cookie header in an HTTP 
> response or 2)
> >by an application programmer creating Cookie objects and 
> adding them to the
> >HttpState.
> >
> This bypasses the creation of the header, which somehow is 
> also in the 
> cookie class.
> 
> >In case 1 the Cookie's domain will *never* be null.  
> HttpClient does the
> >right thing (in my opinion) by calling Cookie.parse() with 
> the domain set to
> >the hostname of the server that sent us the set-cookie 
> header.  If the
> >set-cookie header contains an explicit domain attribute then 
> it updates the
> >Cookie's domain, otherwise it remains the sending hostname.
> >
> >In case 2, someome might call a Cookie constructor with a 
> null domain value.
> >My opinion is that this should be illegal, and should throw an
> >IllegalArgumentException.  Such a cookie would be useless 
> because we can
> >never send it to any server.  A cookie's domain must match 
> the domain of the
> >host that the request is going to, so without a domain the 
> cookie should
> >never be sent.
> >
> No, we could never send *it* to any server, but we can construct the 
> header from 'null-domained' cookies, using a valid domain 
> name, and the 
> process would work as advertised.
> 
> It seems you're missing the 'create header' and use of the 
> cookie class. 
> Or am I missing something?
> 
> >Now, if someone convinces me that we should allow Cookies to 
> be created with
> >null domains, then I'll need to make sure that the 
> HttpClient doesn't croak
> >on them and that we never try to send them to anyone.  It 
> just seems easier
> >and safer to simply prevent such an abomination from ever 
> being created in
> >the first place.
> >
> That's what we did about a month ago - fix Cookie so it could handle 
> null domains and paths *as properties*. The only piece that 
> was left as 
> an unknown issue was creating a header and parsing cookies from it.
> 
> We do have a 'user' of HttpClient that is using nulls in the cookies 
> domain/path - Cactus.
> 
> -- 
> dIon Gillard, Multitask Consulting
> http://adslgateway.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>
> 

--
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