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:[EMAIL PROTECTED]] > 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" <[EMAIL PROTECTED]> > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> > 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:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
