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 Wed, 06 Mar 2002 22:03:47 GMT
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.

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.

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.

Now lets take a look at what you'll see on the server side (as in your
servlet example below).  The reason I want to address this now is because I
think I just found another cookie bug.  According to RFC 2109/4.3.4, the
cookie header sent by the client should only include the domain attribute if
there was a domain attribute in the set-cookie header (that is, if the
cookie has an explicitly set domain instead of the default).  Currently,
HttpClient always send the domain attribute (well, if it isn't null :->).
So if you're servlet did not explicitly set the domain in the cookie it sent
to the client you probably won't see it come back in the next request.

Another issue, that my or may not be all the important right now, is that we
currently don't do any domain name validation on domains that get passed in
via the constructor.  The specifications provide several requirements for
what a valid cookie domain is (and the requirements are different for
Netscape cookies and RFC 2109 cookies).  We currently validate the domain
restrictions in the Cookie.parse() method, but there's nothing to stop a
malicious programmer from manually creating a cookie with a domain of .com
and manually adding that to the HttpState.


Marc Saegesser 

> -----Original Message-----
> From: Scott Rogers [mailto:scott@scottrogers.org]
> Sent: Wednesday, March 06, 2002 2:49 PM
> To: Jakarta Commons Developers List
> Subject: Re: [httpclient] Constructing Cookies with null 
> domains (again)
> 
> 
> This is a 'Cookie Dump' of a servlet running on WebLogic 6.1.
> 
> Does this mean the cookie domain is null?
> 
> Here is the code that generated it..
> 
>     public static String dumpCookies( HttpServletRequest request)
>     {
>         StringBuffer sb = new StringBuffer();
> 
>         sb.append("\n########Cookies in 
> Reques########################");
>         Cookie[] cookies = request.getCookies();
> 
>         for( int i = 0; i < cookies.length; i++ )
>         {
>             sb.append("\nName: " + cookies[i].getName() );
>             sb.append("\nValue: " + cookies[i].getValue() );
>             sb.append("\nDomain: " + cookies[i].getDomain() );
>             sb.append("\nPath: " + cookies[i].getPath() );
>             sb.append("\nComment: " + cookies[i].getComment() );
>         }
> 
>         sb.append("\n########End of Cookies in 
> Reques#################\n");
>         return sb.toString();
>     }
> 
> ----- Original Message -----
> From: "Marc Saegesser" <Marc.Saegesser@apropos.com>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Sent: Wednesday, March 06, 2002 2:22 PM
> Subject: RE: [httpclient] Constructing Cookies with null 
> domains (again)
> 
> 
> > What I meant was that a cookie always has a domain value, 
> it is either
> > specified explicitly by a domain attribute in the 
> set-cookie header or
> > implicitly as the hostname that it came from.
> >
> > A cookie without a domain is a pretty useless thing; it 
> will *never* be
> sent
> > to anyone.  All of the cookie specs are quite specific 
> about what cookies
> a
> > client is allowed to send to a server and they all require 
> a domain match.
> > No domain --> no match --> never sent.  Any other behaviour 
> would be a
> > serious bug.
> >
> 
> 
> 
> --
> 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