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?
The reason I'm asking this is because I'm interested in some edge cases. Like:
.example.com
be available for www.example.com
?.example.com
be available for example.com
?example.com
be available for www.example.com
?example.com
be available for anotherexample.com
?www.example.com
be able to set cookie for example.com
?www.example.com
be able to set cookie for www2.example.com
?www.example.com
be able to set cookie for .com
?Added 2:
Also, could someone suggest how I should set a cookie so that:
www.example.com
or example.com
;www.example.com
and example.com
.I tested all the cases in the latest Chrome, Firefox, Safari in 2019.
Response to Added:
The previous answers are a little outdated.
RFC 6265 was published in 2011, based on the browser consensus at that time. Since then, there has been some complication with public suffix domains. I've written an article explaining the current situation - http://bayou.io/draft/cookie.domain.html
To summarize, rules to follow regarding cookie domain:
The origin domain of a cookie is the domain of the originating request.
If the origin domain is an IP, the cookie's domain attribute must not be set.
If a cookie's domain attribute is not set, the cookie is only applicable to its origin domain.
If a cookie's domain attribute is set,
It can be derived that a cookie is always applicable to its origin domain.
The cookie domain should not have a leading dot, as in .foo.com
- simply use foo.com
As an example,
x.y.z.com
can set a cookie domain to itself or parents - x.y.z.com
, y.z.com
, z.com
. But not com
, which is a public suffix.y.z.com
is applicable to y.z.com
, x.y.z.com
, a.x.y.z.com
etc.Examples of public suffixes - com
, edu
, uk
, co.uk
, blogspot.com
, compute.amazonaws.com
I was surprised to read section 3.3.2 about rejecting cookies:
http://tools.ietf.org/html/rfc2965
That says that a browser should reject a cookie from x.y.z.com with domain .z.com, because 'x.y' contains a dot. So, unless I am misinterpreting the RFC and/or the questions above, there could be questions added:
Will a cookie for .example.com be available for www.yyy.example.com? No.
Will a cookie set by origin server www.yyy.example.com, with domain .example.com, have it's value sent by the user agent to xxx.example.com? No.
The RFCs are known not to reflect reality.
Better check draft-ietf-httpstate-cookie, work in progress.
The last (third to be exactly) RFC for this issue is RFC-6265 (Obsoletes RFC-2965 that in turn obsoletes RFC-2109).
According to it if the server omits the Domain attribute, the user agent will return the cookie only to the origin server (the server on which a given resource resides). But it's also warning that some existing user agents treat an absent Domain attribute as if the Domain attribute were present and contained the current host name (For example, if example.com returns a Set-Cookie header without a Domain attribute, these user agents will erroneously send the cookie to www.example.com as well).
When the Domain attribute have been specified, it will be treated as complete domain name (if there is the leading dot in attribute it will be ignored). Server should match the domain specified in attribute (have exactly the same domain name or to be a subdomain of it) to get this cookie. More accurately it specified here.
So, for example:
Domain=.example.com
is equivalent to Domain=example.com
Domain=www.example.com
will close the way for www4.example.comPS: trailing comma in Domain attribute will cause the user agent to ignore the attribute =(
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.
There are rules that determine whether a browser will accept the Set-header response header (server-side cookie writing), a slightly different rules/interpretations for cookie set using Javascript (I haven't tested VBScript).
Then there are rules that determine whether the browser will send a cookie along with the page request.
There are differences between the major browser engines how domain matches are handled, and how parameters in path values are interpreted. You can find some empirical evidence in the article How Different Browsers Handle Cookies Differently
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.
*
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
.
Source: Stackoverflow.com