由于奇怪的域/子域cookie问题,我得到了,我想知道浏览器如何处理cookie。如果他们用不同的方式做这件事,知道其中的区别也会很好。

换句话说,当浏览器接收到一个cookie时,该cookie可能有一个域和一个路径附加到它。或者不是,在这种情况下,浏览器可能会用一些默认值代替它们。问题1:它们是什么?

稍后,当浏览器准备发出请求时,它会检查它的cookie并过滤掉应该为该请求发送的cookie。它通过将它们与请求路径和域进行匹配来做到这一点。问题2:匹配规则是什么? 补充道:

我问这个问题是因为我对一些边缘情况感兴趣。如:

用于。example.com的cookie可以用于www.example.com吗? example.com的cookie是否可用于example.com? example.com的cookie可以用于www.example.com吗? example.com的cookie是否可用于anotherexample.com? www.example.com可以为example.com设置cookie吗? www.example.com是否可以为www2.example.com设置cookie ? www.example.com是否可以为。com设置cookie ? 等。

补充2:

还有,谁能建议一下我应该如何设置cookie,以便:

可以通过www.example.com或example.com设置; 它可以通过www.example.com和example.com访问。


当前回答

众所周知,rfc并不能反映现实。

最好检查draft-ietf-httpstate-cookie,工作正在进行中。

其他回答

之前的答案有点过时了。

基于当时的浏览器共识,RFC 6265于2011年发布。 从那时起,公共后缀域名就出现了一些复杂情况。我已经写了一篇文章解释目前的情况- http://bayou.io/draft/cookie.domain.html

综上所述,cookie域的规则如下:

The origin domain of a cookie is the domain of the originating request. If the origin domain is an IP, the cookie's domain attribute must not be set. If a cookie's domain attribute is not set, the cookie is only applicable to its origin domain. If a cookie's domain attribute is set, the cookie is applicable to that domain and all its subdomains; the cookie's domain must be the same as, or a parent of, the origin domain the cookie's domain must not be a TLD, a public suffix, or a parent of a public suffix.

可以推导出cookie总是适用于它的原始域。

cookie域不应该有一个前导点,就像。foo.com -简单地使用foo.com

举个例子,

X.y.z.com可以为自己或父母设置cookie域- X.y.z.com, y.z.com, z.com。但不是com,它是一个公共后缀。 域名=y.z.com的cookie适用于y.z.com、x.y.z.com、a.x.y.z.com等。

公共后缀的例子- com, edu, uk, co.uk, blogspot.com, compute.amazonaws.com

这个问题的最后一个(确切地说是第三个)RFC是RFC-6265(废弃RFC-2965,反过来又废弃RFC-2109)。

根据它,如果服务器省略了Domain属性,用户代理将只将cookie返回给原始服务器(给定资源所在的服务器)。但它也警告说,一些现有的用户代理会将缺少的Domain属性视为存在并包含当前主机名的Domain属性(例如,如果example.com返回一个没有Domain属性的Set-Cookie报头,这些用户代理也会错误地将cookie发送到www.example.com)。

当Domain属性被指定时,它将被视为完整的域名(如果属性中有前导点,它将被忽略)。服务器必须匹配属性中指定的域(具有完全相同的域名或它的子域名)才能获得此cookie。更准确地说,它在这里指定了。

举个例子:

cookie属性Domain=.example.com等价于Domain=example.com 具有此类域名属性的cookie将可用于example.com和www.example.com 具有此类域名属性的cookie将无法用于another-example.com 指定cookie属性如Domain=www.example.com将关闭www4.example.com

PS: Domain属性中的尾随逗号会导致用户代理忽略属性=(

我很惊讶地读到3.3.2节关于拒绝cookie的内容:

https://www.rfc-editor.org/rfc/rfc2965

这意味着浏览器应该拒绝来自x.y.z.com的域名为。z.com的cookie,因为“x.y”包含一个点。所以,除非我误解了RFC和/或上面的问题,否则可能会添加一些问题:

用于。example.com的cookie可以用于www.yyy.example.com吗?不。

一个由源服务器www.yyy.example.com设置的cookie,域名为。example.com,它的值会被用户代理发送到xxx.example.com吗?不。

众所周知,rfc并不能反映现实。

最好检查draft-ietf-httpstate-cookie,工作正在进行中。

有一些规则决定浏览器是否接受set -header响应报头(服务器端cookie写入),对于使用Javascript的cookie集有一个稍微不同的规则/解释(我还没有测试VBScript)。

然后,有一些规则确定浏览器是否会随页面请求一起发送cookie。

主要的浏览器引擎在处理域匹配和解释路径值中的参数方面存在差异。您可以在文章《不同浏览器如何不同地处理cookie》中找到一些经验证据