由于我遇到了奇怪的域/子域cookie问题，我想知道浏览器如何处理cookie。如果他们以不同的方式做到这一点，那么了解差异也会很好。
换句话说 - 当浏览器收到cookie时，该cookie可能有一个域和一个附加到它的路径。或者不是，在这种情况下，浏览器可能会替换它们的一些默认值。问题1：他们是什么？
稍后，当浏览器即将发出请求时，它会检查其cookie并过滤掉它应该为该请求发送的cookie。它通过将它们与请求路径和域匹配来实现。问题2：匹配规则是什么？
<小时/> 的加了：
我问这个的原因是因为我对一些边缘情况感兴趣。像：
.example.com的{{1}} Cookie是否可用？www.example.com的{{1}} Cookie是否可用？.example.com的{{1}} Cookie是否可用？example.com的{{1}} Cookie是否可用？example.com能为www.example.com设置Cookie吗？example.com能为anotherexample.com设置Cookie吗？www.example.com能为example.com设置Cookie吗？已添加2：
此外，有人可以建议我应该如何设置cookie：
www.example.com或www2.example.com; www.example.com和.com都可以访问。答案 0 :(得分：327)
虽然RFC 2965（Set-Cookie2已经过时RFC 2109）应定义当前的Cookie，但大多数浏览器并不完全支持但只需遵守original specification by Netscape。
Domain 属性值与有效域之间存在区别：前者取自Set-Cookie头字段，后者是该属性值的解释。根据RFC 2965，以下内容应适用：
.开头，则客户端将添加该值。< / LI>
拥有有效域，它还必须domain-match当前请求的域被设置;否则cookie将被修改。同样的规则适用于选择要在请求中发送的cookie。
将这些知识映射到您的问题，以下内容应适用：
Domain=.example.com 将可用于 www.example.com Domain=.example.com 将可用于 example.com Domain=example.com将转换为.example.com，因此 也可用于 www.example.com 要为 www.example.com 和 example.com 设置和阅读Cookie，请将其设置为Domain=example.com和{{1} } 分别。但第一个（.www.example.com）只能访问该域下的其他域（例如 foo.www.example.com 或 bar.www.example.com ） example.com 下面的任何其他域也可以访问.example.com（例如 foo.example.com 或 bar.example.com ）。
答案 1 :(得分：95)
以前的答案有点过时了。
RFC 6265于2011年发布，基于当时的浏览器共识。 从那以后，公共后缀域出现了一些复杂化。我写了一篇解释当前情况的文章 - http://bayou.io/draft/cookie.domain.html
总结一下，有关cookie域的规则：
Cookie的原始域是原始请求的域。
如果原始域是IP，则不得设置cookie的域属性。
如果未设置Cookie的域属性，则Cookie仅适用于其原始域。
如果设置了Cookie的域属性，
可以推导出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
答案 2 :(得分：8)
此问题的最后一个（确切地说是第三个）RFC是RFC-6265（废弃RFC-2965，后者反过来废弃RFC-2109）。
According to it如果服务器省略了Domain属性，则用户代理将仅将cookie返回到源服务器（给定资源所在的服务器）。但它也警告一些现有的用户代理处理缺少的Domain属性，就好像Domain属性存在并包含当前主机名（例如，如果 example.com 返回如果没有Domain属性的Set-Cookie标头，这些用户代理也会错误地将cookie发送到www.example.com。
当指定了Domain属性时，它将被视为完整的域名（如果属性中有前导点，它将被忽略）。服务器应匹配属性中指定的域（具有完全相同的域名或是其子域）以获取此cookie。更准确地说是specified here。
所以，例如：
Domain=.example.com相当于Domain=example.com Domain=www.example.com这样的Cookie属性将关闭 www4.example.com PS：Domain属性中的尾随逗号将导致用户代理忽略该属性=（
答案 3 :(得分：7)
对于RFC2965的内容进行广泛的覆盖审查。当然，这并不一定意味着所有浏览器的行为都完全相同。
但是，一般情况下，如果在cookie中没有指定，则默认路径的规则是Set-Cookie标头到达的URL中的路径。同样，域的默认值是Set-Cookie到达的URL中的完整主机名。
域的匹配规则要求cookie域与发出请求的主机相匹配。 Cookie可以通过include *指定更广泛的域匹配。在Set-Cookie的域属性中（浏览器可能会有所不同）。匹配路径（假设域匹配）是一个简单的事情，请求的路径必须在cookie上指定的路径内。通常会话cookie使用path = /或path = / applicationName /设置，因此cookie可用于应用程序中的所有请求。
<小时/> 对已添加的回复：
*我现在无法对此进行测试，但我得知道，至少IE7 / 6会将路径example.com视为.example.com。
答案 4 :(得分：4)
我在2019年的最新Chrome，Firefox，Safari中测试了所有情况。
回复已添加：
答案 5 :(得分：3)
众所周知，RFC不能反映现实。
更好地检查draft-ietf-httpstate-cookie，正在进行中。
答案 6 :(得分：3)
有一些规则可以确定浏览器是否接受Set-header响应头（服务器端cookie编写），使用Javascript（我没有测试过VBScript）对cookie集的规则/解释略有不同。
然后有规则确定浏览器是否会发送cookie以及页面请求。
主要浏览器引擎之间存在差异，如何处理域匹配，以及如何解释路径值中的参数。您可以在文章How Different Browsers Handle Cookies Differently
中找到一些经验证据答案 7 :(得分：2)
我很惊讶地阅读了关于拒绝cookie的第3.3.2节：
http://tools.ietf.org/html/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？没有。
答案 8 :(得分：1)
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。我经常想知道。