subdomain.example.com可以设置一个example.com可以读取的cookie吗？

Question

我简直不敢相信这很难确定。

即使阅读了 RFC，我也不清楚 subdomain.example.com 上的服务器是否可以设置 example.com 可以读取的 cookie。

subdomain.example.com 可以设置一个域属性为.example.com 的cookie。RFC 2965 似乎明确声明不会将此类 cookie 发送到 example.com，但同样表示，如果您设置 Domain=example.com，则会在前面加上一个点，就像您说的 .example.com 一样。综上所述，这似乎是说，如果 example.com 返回设置了一个带有 Domain=example.com 的 cookie，则它不会取回该 cookie！那不可能是对的。

任何人都可以澄清规则的真正含义吗？

Answer 1

引用您阅读的同一个RFC2109：

       * 来自 request-host x.foo.com for Domain=.foo.com 的 Set-Cookie 会
         被接受。

所以subdomain.example.com可以为.example.com. 到现在为止还挺好。

       以下规则适用于从中选择适用的 cookie 值
       在用户代理拥有的所有 cookie 中。

       域选择
            源服务器的完全限定主机名必须域匹配
            cookie 的域属性

那么我们有域匹配吗？

   * A 是 FQDN 字符串，格式为 NB，其中 N 是非空名称
     字符串，B 的格式为 .B'，B' 是 FQDN 字符串。（所以，xycom
     域匹配 .y.com 但不匹配 y.com。）

但是现在example.com不会.example.com根据定义进行域匹配。但是www.example.com（或域中的任何其他“非空名称”）会。该 RFC 理论上已被RFC2965废弃，该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所做的那样）。