引用与您阅读的相同的RFC2109:
*来自请求主机x.foo.com的Domain = .foo.com的Set-Cookie将
被接受。
因此subdomain.example.com
可以为设置Cookie .example.com
。到目前为止,一切都很好。
以下规则适用于从中选择适用的Cookie值
用户代理拥有的所有cookie中。
域选择
原始服务器的标准主机名必须与域匹配
Cookie的Domain属性
那么我们有一个域名匹配吗?
* A是FQDN字符串,格式为NB,其中N是非空名称
字符串,B的形式为.B',而B'是FQDN字符串。(因此,xycom
域匹配.y.com,但不匹配y.com。)
但是根据定义,现在example.com
不会进行域匹配.example.com
。但是www.example.com
(或域中任何其他“非空名称”)都可以。该RFC在理论上已被RFC2965淘汰,后者规定了在Set-Cookie2
操作域上强制使用前导点的事情。
正如@Tony所指出的,更重要的是真实世界。要了解实际的用户代理正在做什么,请参阅
Firefox 3的nsCookieService.cpp
和
Chrome浏览器的cookie_monster.cc
对于观点纳入什么实际的网站都在做,尝试演奏wget
使用--save-cookies
,--load-cookies
以及--debug
看看发生了什么事情。
您可能会发现,实际上,大多数站点都使用Set-Cookie
旧的RFC规范中带有“主机”值的某种组合,隐含地没有前导点(如twitter.com那样)或设置域值(有前导点)并重定向像一台服务器www.example.com
(如google.com一样)。