How do browser cookie domains work?

Question

Due to weird domain/subdomain cookie issues that I'm getting, I'd like to know how browsers handle cookies. If they do it in different ways, it would also be nice to know the differences.

In other words - when a browser receives a cookie, that cookie MAY have a domain and a path attached to it. Or not, in which case the browser probably substitutes some defaults for them. Question 1: what are they?

Later, when the browser is about to make a request, it checks its cookies and filters out the ones it should send for that request. It does so by matching them against the requests path and domain. Question 2: what are the matching rules?

---

Added:

The reason I'm asking this is because I'm interested in some edge cases. Like:

• Will a cookie for .example.com be available for www.example.com?
• Will a cookie for .example.com be available for example.com?
• Will a cookie for example.com be available for www.example.com?
• Will a cookie for example.com be available for anotherexample.com?
• Will www.example.com be able to set cookie for example.com?
• Will www.example.com be able to set cookie for www2.example.com?
• Will www.example.com be able to set cookie for .com?
• Etc.

Added 2:

Also, could someone suggest how I should set a cookie so that:

• It can be set by either www.example.com or example.com;
• It is accessible by both www.example.com and example.com.

Answer 1

For an extensive coverage review the contents of RFC2965. Of course that doesn't necessarily mean that all browsers behave exactly the same way.

However in general the rule for default Path if none specified in the cookie is the path in the URL from which the Set-Cookie header arrived. Similarly the default for the Domain is the full host name in the URL from which the Set-Cookie arrived.

Matching rules for the domain require the cookie Domain to match the host to which the request is being made. The cookie can specify a wider domain match by include *. in the domain attribute of Set-Cookie (this one area that browsers may vary). Matching the path (assuming the domain matches) is a simple matter that the requested path must be inside the path specified on the cookie. Typically session cookies are set with path=/ or path=/applicationName/ so the cookie is available to all requests into the application.

---

Response to Added:

• Will a cookie for .example.com be available for www.example.com? Yes
• Will a cookie for .example.com be available for example.com? Don't Know
• Will a cookie for example.com be available for www.example.com? Shouldn't but... *
• Will a cookie for example.com be available for anotherexample.com? No
• Will www.example.com be able to set cookie for example.com? Yes
• Will www.example.com be able to set cookie for www2.example.com? No (Except via .example.com)
• Will www.example.com be able to set cookie for .com? No (Can't set a cookie this high up the namespace nor can you set one for something like .co.uk).

* I'm unable to test this right now but I have an inkling that at least IE7/6 would treat the path example.com as if it were .example.com.

Answer 2

Although there is the RFC 2965 (Set-Cookie2, had already obsoleted [RFC 2109]) that should define the cookie nowadays, most browsers don’t fully support that but just comply to the original specification by Netscape.

But according to the RFC 2965, the following should apply:

• Cookie for .example.com will be available for www.example.com
• Cookie for .example.com will be available for example.com
• Cookie for example.com will be converted to .example.com and thus will be available for www.example.com
• Cookie for example.com will not be available for anotherexample.com
• www.example.com will be able to set cookie for example.com
• www.example.com will not be able to set cookie for www2.example.com
• www.example.com will not be able to set cookie for .com

And to set and read a cookie for/by www.example.com and example.com, you can either set it for .www.example.com or .example.com. But the first (.www.example.com) will only be accessible for other domains below that domain (e.g. foo.www.example.com or bar.www.example.com) where .example.com can also be accessed by any other domain below example.com (e.g. foo.example.com or bar.example.com).

Answer 3

Will www.example.com be able to set cookie for .com?

No, but example.com.fr may be able to set a cookie for example2.com.fr. Firefox protects against this by maintaining a list of TLDs: http://securitylabs.websense.com/content/Blogs/3108.aspx

Apparently Internet Explorer doesn't allow two-letter domains to set cookies, which I suppose explains why o2.ie simply redirects to o2online.ie. I'd often wondered that.

Answer 4

The RFCs are known not to reflect reality.

Better check draft-ietf-httpstate-cookie, work in progress.