由于奇怪的域/子域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访问。
要获得广泛的覆盖，请查看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 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)。
我很惊讶地读到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是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属性中的尾随逗号会导致用户代理忽略属性=(
之前的答案有点过时了。
基于当时的浏览器共识，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
2019年，我在最新的Chrome、Firefox和Safari中测试了所有的保护套。
回复新增:
Will a cookie for .example.com be available for www.example.com? YES
Will a cookie for .example.com be available for example.com? YES
Will a cookie for example.com be available for www.example.com? NO, Domain without wildcard only matches itself.
Will a cookie for example.com be available for anotherexample.com? NO
Will www.example.com be able to set cookie for example.com? NO, it will be able to set cookie for '.example.com', but not 'example.com'.
Will www.example.com be able to set cookie for www2.example.com? NO. But it can set cookie for .example.com, which www2.example.com can access.
Will www.example.com be able to set cookie for .com? NO
