浏览器在传递cookie时与domain有关的策略

最近在排查一个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.