最近在排查一个ie6特定版本(2900.2180 xp sp2 gdr)中才会出现的cookie传递问题,因此查阅了rfc2109.http://tools.ietf.org/html/rfc2109
chrome/ff下向a.b.c.com发送数据,不会提交domain为b.c.com的cookie,但会提交.b.c.com的cookie,因为能提交的cookie必须满足domain-matches条件,如rfc2109所言,x.y.com domain-matches .y.com but not y.com。所以这应该算是ie6特定版本的一个bug自己的实现,它提交了b.c.com的cookie。另一方面,rfc2109规定,An explicitly specified domain must always start with a dot.Domain Defaults to the request-host. (Note that there is no dot at the beginning of request-host.)
为什么默认值选择给出一个不规范的domain而不是主动加个点在最前面呢?
结论:
浏览器在传递cookie时,会传递本域名及其父域(必须以.开头)的所有cookie。即向a.b.c.com发送数据,会带上的cookie有:
a.b.c.com
.b.c.com
.c.com
如果服务器要指定cookie的domain,应该以.开头。
=============追加内容===============
如此文所言:http://stackoverflow.com/questions/1062963/how-do-browser-cookie-domains-work
RFC 2109 已经被RFC 2965 取代
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.
There is a distinction between the Domain attribute value and the effective domain: the former is taken from the Set-Cookie
header field and the latter is the interpretation of that attribute value. According to the RFC 2965, the following should apply:
- If the Set-Cookie header field does not have a Domain attribute, the effective domain is the domain of the request.
- If there is a Domain attribute present, its value will be used as effective domain (if the value does not start with a
.
it will be added by the client).
Having the effective domain it must also domain-match the current requested domain for being set; otherwise the cookie will be revised. The same rule applies for choosing the cookies to be sent in a request.