I simply cannot believe this is quite so hard to determine.
Even having read the RFCs, it's not clear to me if a server at subdomain.example.com can set a cookie that can be read by example.com.
subdomain.example.com can set a cookie whose Domain attribute is .example.com. RFC 2965 seems to explicitly state that such a cookie will not be sent to example.com, but then equally says that if you set Domain=example.com, a dot is prepended, as if you said .example.com. Taken together, this seems to say that if example.com returns sets a cookie with Domain=example.com, it doesn't get that cookie back! That can't be right.
Can anyone clarify what the rules really are?
Best Answer
Quoting from the same RFC2109 you read:
So
subdomain.example.com
can set a cookie for.example.com
. So far so good.So do we have a domain-match?
But now
example.com
wouldn't domain-match.example.com
according to the definition. Butwww.example.com
(or any other "non-empty name" in the domain) would. This RFC is in theory obsoleted by RFC2965, which dictated things about forcing a leading dot for domains onSet-Cookie2
operations.More important, as noted by @Tony, is the real world. For a glimpse into what actual user agents are doing, see
and
For perspective into what actual sites are doing, try playing with
wget
using--save-cookies
,--load-cookies
, and--debug
to see what's going on.You'll likely find that in fact most sites are using some combination of
Set-Cookie
from the older RFC spec with "Host" values, implicitly without a leading dot (as twitter.com does) or setting Domain values (with a leading dot) and redirecting to a server likewww.example.com
(as google.com does).