浏览器cookie域如何工作？

由于我遇到的奇怪的域/子域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能够设置cookie中example.com？
• 将www.example.com能够设置cookie中www2.example.com？
• 将www.example.com能够设置cookie中.com？
• 等等。

新增2：

另外，有人可以建议我应该如何设置Cookie，以便：

• 可以通过www.example.com或设置example.com。
• www.example.com和均可访问example.com。

尽管现在有应该定义cookie 的RFC 2965（Set-Cookie2已经过时的RFC 2109），但是大多数浏览器并不完全支持cookie，而只是符合Netscape的原始规范。

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

• 如果Set-Cookie标头字段不具有Domain属性，则有效域是请求的域。
• 如果存在“ 域”属性，则其值将用作有效域（如果该值不以开头，.则它将由客户端添加）。

拥有有效域后，它还必须与当前请求的域进行域匹配以进行设置；否则，cookie将被修改。相同的规则适用于选择要在请求中发送的cookie。

将这些知识映射到您的问题上，应遵循以下条件：

• Cookie的使用Domain=.example.com 将可用于www.example.com
• Cookie的使用Domain=.example.com 将可用于example.com
• Cookie与Domain=example.com将被转换为.example.com并因此将也可用于www.example.com
• Cookie的使用Domain=example.com将不会用于提供anotherexample.com
• www.example.com 将能够为example.com设置cookie
• www.example.com将无法为www2.example.com设置cookie
• www.example.com将无法为.com设置Cookie

并且要设置和读取www.example.com和example.com的cookie .www.example.com，请.example.com分别为和设置它。但是第一个（.www.example.com）仅可用于该域下的其他域（例如foo.www.example.com或bar.www.example.com），而example.com.example.com下的任何其他域（例如foo）也可以访问该域。 example.com或bar.example.com）。

先前的答案有些过时。

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

总而言之，有关Cookie域的规则如下：

• Cookie 的原始域是原始请求的域。

• 如果源域是IP，则不得设置cookie的域属性。

• 如果未设置cookie的domain属性，则该cookie仅适用于其原始域。

• 如果设置了cookie的domain属性，

  • Cookie适用于该域及其所有子域；
  • Cookie的域必须与原始域相同或作为其父域
  • Cookie的域不得为TLD，公共后缀或公共后缀的父级。

可以得出Cookie始终适用于其原始域的信息。

Cookie域不应像前面那样.foo.com-只需使用foo.com

举个例子，

• x.y.z.com可以在Cookie域设置为自己或父母- ，x.y.z.com，。y.z.com z.com但不是com，这是一个公共后缀。
• 与域一个cookie = y.z.com适用于y.z.com，x.y.z.com，a.x.y.z.com等。

公共后缀的例子- ，com，edu，uk，，co.ukblogspot.comcompute.amazonaws.com

有关广泛的内容，请查阅RFC2965的内容。当然，这并不一定意味着所有浏览器的行为都完全相同。

但是，通常，如果Cookie中未指定任何默认路径，则默认路径的规则是Set-Cookie标头从其到达的URL中的路径。同样，域的默认值是Set-Cookie到达的URL中的完整主机名。

域的匹配规则要求Cookie域与要向其发出请求的主机匹配。Cookie可以通过包含*指定更广泛的域匹配。在Set-Cookie的domain属性中（浏览器的这一区域可能有所不同）。匹配路径（假设域匹配）很简单，请求的路径必须在cookie上指定的路径内。通常，会话cookie是使用path = /或path = / applicationName /设置的，因此cookie可供应用程序中的所有请求使用。

• .example.com的cookie是否可用于www.example.com？ 是
• .example.com的cookie是否可用于example.com？ 不知道
• www.example.com是否可以使用example.com的cookie？应该不会，但... *
• example.com的cookie是否可用于anotherexample.com？ 没有
• www.example.com可以为example.com设置cookie吗？ 是
• www.example.com能够为www2.example.com设置cookie吗？ 否 （通过.example.com除外）
• www.example.com可以为.com设置cookie吗？ 否 （无法在Cookie的名称空间上设置cookie，也不能为.co.uk之类的设置cookie）。

*我现在无法对此进行测试，但我暗示至少IE7 / 6会将路径example.com视为真实路径 .example.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
• 具有此类Domain属性的Cookie将可用于example.com和www.example.com
• 具有此类Domain属性的Cookie 不适用于 another-example.com
• 指定类似cookie的属性Domain=www.example.com将关闭www4.example.com的方式

PS：“域”属性中的尾部逗号将导致用户代理忽略该属性=（

我在2019年的最新Chrome，Firefox，Safari中测试了所有情况。

回复：

• .example.com的cookie是否可用于www.example.com？是
• .example.com的cookie是否可用于example.com？是
• www.example.com是否可以使用example.com的cookie？否，没有通配符的域只能匹配自己。
• example.com的cookie是否可用于anotherexample.com？没有
• www.example.com可以为example.com设置cookie吗？否，它将能够为“ .example.com”设置cookie，但不能为“ example.com”设置cookie。
• www.example.com能够为www2.example.com设置cookie吗？NO。但是它可以为.example.com设置cookie，www2.example.com可以访问它。
• www.example.com可以为.com设置cookie吗？没有

众所周知，RFC无法反映现实。

更好地检查draft-ietf-httpstate-cookie，正在进行中。

有一些规则可以确定浏览器是否接受Set-header响应头（服务器端cookie编写），使用Javascript设置cookie的规则/解释稍有不同（我尚未测试VBScript）。

然后是确定浏览器是否将与页面请求一起发送cookie的规则。

主要浏览器引擎之间的区别在于如何处理域匹配以及如何解释路径值中的参数。您可以在文章“不同的浏览器如何不同地处理Cookie”中找到一些经验证据。

我很惊讶地阅读有关拒绝Cookie的3.3.2节：

http://tools.ietf.org/html/rfc2965

也就是说，浏览器应拒绝域为.z.com的xyzcom的cookie，因为“ xy”包含一个点。因此，除非我对RFC和/或以上问题有误解，否则可能会添加以下问题：

.example.com的cookie是否可用于www.yyy.example.com？没有。

由源服务器www.yyy.example.com（域为.example.com）设置的cookie是否具有由用户代理发送到xxx.example.com的值？没有。

将www.example.com能够设置cookie中.com？

否，但是example.com.fr可以为设置Cookie example2.com.fr。Firefox通过维护TLD列表来防止这种情况：http : //securitylabs.websense.com/content/Blogs/3108.aspx

显然Internet Explorer不允许两个字母的域设置cookie，我想这解释了为什么o2.ie简单地重定向到o2online.ie。我经常想知道。