Thank you for clarifying.- I forgot to mention the Set-Cookie domain must match the suffix ofthe originating host.- Neither of us mentioned that IP Addresses are exempt from partialdomain matching. IP Addresses are allowed as the Cookie domain forexact matches.- We had difficulty receiving Cookies for c.b.a.com set by b.a.com atthe .a.com level during the last decade (1998?). Hopefully all modernbrowsers work as specified in the RFC. I should have marked thisinformation as suggestive for testing rather than definitive.
"The server "example.com" can set a cookie for ".example.com"."This should be inaccurate because ".example.com" is not a suffix ofthe originating server. Server "example.com" may be able to setCookies for itself -- the RFC suggests the server name is used if noDomain parameter is specified in Set-Coookie: "Domain Defaults to the request-host. (Note that there is no dotat the beginning of request-host.)"The two-dots rule only applies to Domain parameters. I have not tested.
solprovider
On 7/18/08, André Warnier <aw@xxxxxxxxxx> wrote:> First, I found a thread which might provide some useful information for the> original poster :> http://www.theserverside.com/patterns/thread.tss?thread_id=31258>> Second,> solprovider@xxxxxxxxxx wrote:> > On 7/17/08, jamanbo jamanbo <jamanbo@xxxxxxxxxxxxxx> wrote:> Rescpectfully, I believe there are several inaccuracies in the explanation> given by solprovider, and this might induce the OP in error.> The notes below represent my own understanding of the matter, based on> http://www.w3.org/Protocols/rfc2109/rfc2109> and> http://en.wikipedia.org/wiki/HTTP_cookie#Implementation> Please correct me if I am wrong.>> > Cookies are set for the parent domain part of the server name. The> > Cookie for "espn.example.com" is set at".example.com".>> The server "espn.example.com" can technically (try to) set a cookie for> whatever domain it chooses, via a "Set-Cookie" header. By default (when not> specified), the cookie domain is understood as being the domain that exactly> matches the server's FQDN (fully-qualified domain name, like> "a.example.com").>> Now whether the browser accepts it is another story.>> A browser respectful of the specification would only accept a cookie from a> server, if the server's own domain "belongs to" (is a sub-domain of) the> cookie domain.> For example, from a server known as "a.b.c.example.com", a browser will> accept a cookie for the domain "a.b.c.example.com" or ".b.c.example.com" or> ".c.example.com" or ".example.com" (but not for ".com" because that domain> does not contain at least two dots).>> (The reason for that is that it is considered unsafe that a server> "www.kgb.ru.gov" should be able to set a cookie for the server> "www.cia.us.gov" for instance).>> > Cookies cannot be set at the TLD level.> >> True in a way, see above, but only because the browser should not accept a> cookie for a domain that does not contain at least 2 dots.>> Default domain no-name servers>> > ("example.com") cannot use Cookies because the Cookie would be set at> > the ".com" TLD.> >> The server "example.com" can set a cookie for ".example.com".> Browsers will save the Cookie>> > at the next level (".example.com") and send the Cookie with every> > request to *.example.com. A server name at the same level must be> > specified. Requests to "example.com" and> > "server.subdomain.example.com" will not include the Cookie.> >> The browser will save the cookie with the domain exactly as specified in> the cookie, it this is valid (iow the domain of the cookie contains at least> 2 dots, and the server issuing the cookie is a member of that domain).>> A cookie set for ".example.com" will be sent by the browser with any> request to "a.b.c.example.com", or ".b.c.example.com", or ".c.example.com"> or ".example.com".> A cookie set for ".c.example.com" will be sent with every request to a> server "a.b.c.example.com" or ".b.c.example.com" or ".c.example.com", but> not for ".example.com" not for "d.example.com" e.g.> André
|