Vincent, I've written quite a bit on this topic over the last few weeks, so you might find some of the stuff in list archives useful. I'll try to summarize things again here.
All cookies have a domain and path associated with them. The path can be specified explicitly using attributes on the set-cookie header or they be set to default values as defined by RFC 2109. The domain and path are important because they determine what cookies are allowed to be sent with later requests (in a coookie header). There are very explicit rules in RFC 2109 about what cookies are allowed be sent a server based on the request's domain and URL. The notion that cookies don't have to have domains and paths comes from, I believe, an incomplete reading of the specification. RFC 2109 does say that the domain and path attributes are optional on the set-coookie header, but it follows up by saying that if those attributes are not in the header that the domain and path are set to known default values (the request host and the request path up to but not including the right-most slash). It is also important to keep track of whether the domain and path attributes were specified explicitly on the set-cookie header or have default values because that effects what data is included in the cookie header (see section 4.3.4 in the paragraph following the syntax description). The createCookieHeader() method generates a cookie header from a list of cookies. The cookies are selected according to the rules given in RFC 2109/4.3.4 (see 'Domain selection', 'Path selection' and 'Max-age selection'). There is no way to select cookies for a cookie header without having a domain and path. Thus, createCookieHeader() now throws an IllegalArgumentException if either domain or path is null. If there are cookies in the list passed to createCookieHeader() that don't have domain or path (i.e. getDomain() or getPath() return null) then they are excluded from the selection process and won't appear in the generated cookie header. This is all based on the domain-match algorithm given in section 2 of RFC 2109. All this is done to prevent cookies from 'escaping' or 'leaking' out to sites where they don't belong (see section 7.2). Marc "Cookie" Saegesser > -----Original Message----- > From: Vincent Massol [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 21, 2002 5:13 PM > To: [EMAIL PROTECTED] > Subject: [HttpClient] Still problems with null domains and paths > > > Hi, > > The Cactus build is breaking again. The error is that Cactus > allows the > user to create cookies with no domain and/or no path. This seems to be > allowed by the spec (RFC 2109) : > > " > set-cookie = "Set-Cookie:" cookies > cookies = 1#cookie > cookie = NAME "=" VALUE *(";" cookie-av) > NAME = attr > VALUE = value > cookie-av = "Comment" "=" value > | "Domain" "=" value > | "Max-Age" "=" value > | "Path" "=" value > | "Secure" > | "Version" "=" 1*DIGIT > > [...]Each cookie begins with a NAME=VALUE pair, followed by > zero or more > semi-colon-separated attribute-value pairs. The syntax for > attribute-value pairs was shown earlier. The specific > attributes and the > semantics of their values follows. The NAME=VALUE attribute- > value pair > must come first in each cookie. The others, if present, can > occur in any > order [...] > " > > However the method Cookie.createCookieHeader(...) does not allow for > null domains and paths. > > Thus, when I call in cactus : > > Header cookieHeader = > org.apache.commons.httpclient.Cookie.createCookieHeader( > HttpClientHelper.getDomain(theRequest, theConnection), > HttpClientHelper.getPath(theRequest, theConnection), > httpclientCookies); > > where httpclientCookies is an array of cookies with no path > nor domain, > the Cookie.match() code in createCookieHeader() fails and thus > createCookieHeader returns null, which is not correct according to the > spec above. > > Am I missing something ? :-) > > Thanks > -Vincent > > > > -- > 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]>
