由于我遇到了奇怪的域/子域 cookie 问题，我想知道浏览器如何处理 cookie。如果他们以不同的方式做到这一点，那么了解这些差异也会很高兴。
换句话说 - 当浏览器接收到一个 cookie 时，该 cookie 可能有一个域和一个附加到它的路径。或者不是，在这种情况下，浏览器可能会用一些默认值代替它们。问题1：它们是什么？
稍后，当浏览器即将发出请求时，它会检查其 cookie 并过滤掉它应该为该请求发送的那些。它通过将它们与请求路径和域进行匹配来实现。问题2：匹配规则是什么？
添加：
我问这个的原因是因为我对一些边缘情况感兴趣。喜欢：
.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？
www.example.com 能否为 .com 设置 cookie？
等等。
添加2：
另外，有人可以建议我应该如何设置一个cookie，以便：
它可以由 www.example.com 或 example.com 设置；
www.example.com 和 example.com 都可以访问它。
尽管现在应该定义 cookie 的 RFC 2965（Set-Cookie2，已经过时的 RFC 2109），但大多数浏览器并不完全支持它，而只是遵守 original specification by Netscape。
Domain 属性值和有效域之间存在区别：前者取自 Set-Cookie 标头字段，后者是该属性值的解释。根据 RFC 2965，以下内容应适用：
如果 Set-Cookie 头域没有 Domain 属性，则有效域为请求的域。
如果存在 Domain 属性，则其值将用作有效域（如果该值不以 . 开头，它将由客户端添加）。
拥有有效域，它还必须 domain-match 设置当前请求的域；否则 cookie 将被修改。相同的规则适用于选择要在请求中发送的 cookie。
将这些知识映射到您的问题上，应适用以下内容：
Domain=.example.com 的 Cookie 将可用于 www.example.com
Domain=.example.com 的 Cookie 将可用于 example.com
Domain=example.com 的 Cookie 将转换为 .example.com，因此也可用于 www.example.com
Domain=example.com 的 Cookie 将不可用于 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 的域属性，则该 cookie 仅适用于其源域。
如果设置了 cookie 的域属性，则该 cookie 适用于该域及其所有子域； cookie 的域必须与原始域相同，或者是其父域 cookie 的域不能是 TLD、公共后缀或公共后缀的父级。
cookie 适用于该域及其所有子域；
cookie 的域必须与源域相同，或者是源域的父域
cookie 的域不能是 TLD、公共后缀或公共后缀的父级。
可以得出，cookie 始终适用于其源域。
cookie 域不应有前导点，如 .foo.com - 只需使用 foo.com
举个例子，
xyzcom 可以为自己或父母设置 cookie 域 - xyzcom、yzcom、z.com。但不是 com，它是一个公共后缀。
domain=yzcom 的 cookie 适用于 yzcom、xyzcom、axyzcom 等。
公共后缀示例 - com、edu、uk、co.uk、blogspot.com、compute.amazonaws.com
x.y.z.com 可以将 cookie 设置为 z.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，也不能为 .co.uk 之类的东西设置一个 cookie）。
* 我现在无法对此进行测试，但我知道至少 IE7/6 会将路径 example.com 视为 .example.com。
此问题的最后一个（确切地说是第三个）RFC 是 RFC-6265（过时的 RFC-2965 反过来又过时了 RFC-2109）。
According to it 如果服务器省略 Domain 属性，用户代理将仅将 cookie 返回到 源服务器（给定资源所在的服务器）。但是也警告，一些现有的用户代理将缺少的域属性视为存在域属性并包含当前主机名（例如，如果 example.com 返回没有域属性的 Set-Cookie 标头，这些用户代理也会错误地将 cookie 发送到 www.example.com）。
当 Domain 属性被指定时，它将被视为完整的域名（如果属性中有前导点将被忽略）。服务器应该匹配属性中指定的域（具有完全相同的域名或作为它的子域）才能获取此 cookie。更准确地说是specified here。
因此，例如：
cookie 属性 Domain=.example.com 等价于 Domain=example.com
具有此类域属性的 cookie 可用于 example.com 和 www.example.com
具有此类域属性的 cookie 将不适用于 another-example.com
指定像 Domain=www.example.com 这样的 cookie 属性将关闭 www4.example.com 的方式
PS：Domain 属性中的尾随逗号会导致用户代理忽略该属性 =(
我在 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？不。但它可以为 .example.com 设置 cookie，www2.example.com 可以访问。
www.example.com 能否为 .com 设置 cookie？不
Contrary to earlier specifications, leading dots in domain names (.example.com) are ignored.
有一些规则可以确定浏览器是否会接受 Set-header 响应标头（服务器端 cookie 写入），使用 Javascript 设置的 cookie 的规则/解释略有不同（我没有测试过 VBScript）。
然后有一些规则可以确定浏览器是否将 cookie 与页面请求一起发送。
主要浏览器引擎如何处理域匹配以及如何解释路径值中的参数之间存在差异。您可以在文章 How Different Browsers Handle Cookies Differently 中找到一些经验证据
www.example.com 能否为 .com 设置 cookie？
不可以，但 example.com.fr 可以为 example2.com.fr 设置 cookie。 Firefox 通过维护一个 TLD 列表来防止这种情况发生：http://securitylabs.websense.com/content/Blogs/3108.aspx
显然 Internet Explorer 不允许两个字母的域设置 cookie，我想这解释了为什么 o2.ie 只是重定向到 o2online.ie。我经常想知道这一点。
我很惊讶地阅读了关于拒绝 cookie 的第 3.3.2 节：
https://www.rfc-editor.org/rfc/rfc2965
这表示浏览器应该拒绝来自 xyzcom 域 .z.com 的 cookie，因为“xy”包含一个点。因此，除非我误解了 RFC 和/或上述问题，否则可能会添加一些问题：
.example.com 的 cookie 是否可用于 www.yyy.example.com？不。
由域为 .example.com 的源服务器 www.yyy.example.com 设置的 cookie 是否会将其值由用户代理发送到 xxx.example.com？不。
z.com 的 cookie 应用于 z.com 和 all 子域。
关注公众号
不定期副业成功案例分享
