由于奇怪的域/子域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访问。


当前回答

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

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

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

其他回答

尽管现在有RFC 2965 (Set-Cookie2,已经过时的RFC 2109)来定义cookie,但大多数浏览器并不完全支持它,只是遵从Netscape最初的规范。

Domain属性值和有效域之间有区别:前者来自Set-Cookie报头字段,后者是对该属性值的解释。根据RFC 2965,以下应适用:

如果Set-Cookie报头字段没有Domain属性,则有效域为请求的域。 如果存在Domain属性,则其值将被用作有效域(如果该值不是以。它将由客户端添加)。

有了有效域,它还必须域匹配当前请求的域进行设置;否则cookie将被修改。同样的规则也适用于选择在请求中发送的cookie。


将这些知识映射到你的问题上,下面的方法应该适用:

Cookie with Domain=.example.com will be available for www.example.com Cookie with Domain=.example.com will be available for example.com Cookie with Domain=example.com will be converted to .example.com and thus will also be available for www.example.com Cookie with Domain=example.com will not be available for anotherexample.com www.example.com will be able to set cookie for example.com www.example.com will not be able to set cookie for www2.example.com www.example.com will not be able to set cookie for .com

要为/by www.example.com和example.com设置和读取cookie,请分别为.www.example.com和.example.com设置cookie。但是第一个域名(.www.example.com)只能被该域名下面的其他域名访问(例如foo.www.example.com或bar.www.example.com),其中。example.com也可以被example.com下面的任何其他域名访问(例如foo.example.com或bar.example.com)。

要获得广泛的覆盖,请查看RFC2965的内容。当然,这并不意味着所有浏览器的行为都完全相同。

但是,通常情况下,如果cookie中没有指定默认路径,则默认路径是Set-Cookie报头到达的URL中的路径。类似地,Domain的默认值是来自Set-Cookie的URL中的完整主机名。

Matching rules for the domain require the cookie Domain to match the host to which the request is being made. The cookie can specify a wider domain match by include *. in the domain attribute of Set-Cookie (this one area that browsers may vary). Matching the path (assuming the domain matches) is a simple matter that the requested path must be inside the path specified on the cookie. Typically session cookies are set with path=/ or path=/applicationName/ so the cookie is available to all requests into the application.


__Response to Added:__

Will a cookie for .example.com be available for www.example.com? Yes Will a cookie for .example.com be available for example.com? Don't Know Will a cookie for example.com be available for www.example.com? Shouldn't but... * Will a cookie for example.com be available for anotherexample.com? No Will www.example.com be able to set cookie for example.com? Yes Will www.example.com be able to set cookie for www2.example.com? No (Except via .example.com) Will www.example.com be able to set cookie for .com? No (Can't set a cookie this high up the namespace nor can you set one for something like .co.uk).

*我现在无法测试这个,但我有一个暗示,至少IE7/6会把路径example.com视为。example.com。

之前的答案有点过时了。

基于当时的浏览器共识,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

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

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

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

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

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