浏览器 cookie 域如何工作？
由于我遇到了奇怪的域/子域 cookie 问题，我想知道浏览器如何处理 cookie。 如果他们以不同的方式做事，那么了解其中的差异也很好。
换句话说 - 当浏览器收到 cookie 时，该 cookie 可能附加一个域和一个路径。 或者不是，在这种情况下，浏览器可能会用一些默认值代替它们。 问题1：它们是什么？
稍后，当浏览器要发出请求时，它会检查其 cookie 并过滤掉应为该请求发送的 cookie。 它通过将它们与请求路径和域进行匹配来实现这一点。 问题2：匹配规则是什么？
Added:
我问这个问题的原因是因为我对一些边缘情况感兴趣。 例如：
.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访问。
Due to weird domain/subdomain cookie issues that I'm getting, I'd like to know how browsers handle cookies. If they do it in different ways, it would also be nice to know the differences.
In other words - when a browser receives a cookie, that cookie MAY have a domain and a path attached to it. Or not, in which case the browser probably substitutes some defaults for them. Question 1: what are they?
Later, when the browser is about to make a request, it checks its cookies and filters out the ones it should send for that request. It does so by matching them against the requests path and domain. Question 2: what are the matching rules?
Added:
The reason I'm asking this is because I'm interested in some edge cases. Like:
- Will a cookie for
.example.combe available forwww.example.com? - Will a cookie for
.example.combe available forexample.com? - Will a cookie for
example.combe available forwww.example.com? - Will a cookie for
example.combe available foranotherexample.com? - Will
www.example.combe able to set cookie forexample.com? - Will
www.example.combe able to set cookie forwww2.example.com? - Will
www.example.combe able to set cookie for.com? - Etc.
Added 2:
Also, could someone suggest how I should set a cookie so that:
- It can be set by either
www.example.comorexample.com; - It is accessible by both
www.example.comandexample.com.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
虽然有 RFC 2965 (
Set-Cookie2)，但已经过时的RFC 2109），现在应该定义cookie，大多数浏览器并不完全支持，只是遵守 Netscape 的原始规范。Domain 属性值和有效域之间存在区别：前者取自
Set-Cookie标头字段，后者是该属性值的解释。 根据 RFC 2965，应适用以下规则：.开头，它将由客户端添加）。拥有有效域名，它还必须域名匹配当前请求待设置的域； 否则cookie将被修改。 同样的规则适用于选择要在请求中发送的 cookie。
将这些知识映射到您的问题上，应适用以下内容：
Domain=.example.com的 Cookie 将可用于www.example.comDomain=.example.com的 Cookie 将可用对于 example.comDomain=example.com的 Cookie 将转换为.example.com，因此将也可用于 www.example.comDomain=example 的 Cookie。 com将无法用于 anotherexample.com并为 www.example 设置并读取 cookie .com 和 example.com，将其设置为
.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）。Although there is the RFC 2965 (
Set-Cookie2, had already obsoleted RFC 2109) that should define the cookie nowadays, most browsers don’t fully support that but just comply to the original specification by Netscape.There is a distinction between the Domain attribute value and the effective domain: the former is taken from the
Set-Cookieheader field and the latter is the interpretation of that attribute value. According to the RFC 2965, the following should apply:.it will be added by the client).Having the effective domain it must also domain-match the current requested domain for being set; otherwise the cookie will be revised. The same rule applies for choosing the cookies to be sent in a request.
Mapping this knowledge onto your questions, the following should apply:
Domain=.example.comwill be available for www.example.comDomain=.example.comwill be available for example.comDomain=example.comwill be converted to.example.comand thus will also be available for www.example.comDomain=example.comwill not be available for anotherexample.comAnd to set and read a cookie for/by www.example.com and example.com, set it for
.www.example.comand.example.comrespectively. But the first (.www.example.com) will only be accessible for other domains below that domain (e.g. foo.www.example.com or bar.www.example.com) where.example.comcan also be accessed by any other domain below example.com (e.g. foo.example.com or bar.example.com).以前的答案有点过时了。
RFC 6265 于 2011 年发布，基于当时的浏览器共识。
从那时起，公共后缀域就出现了一些复杂情况。 我写了一篇文章解释当前情况 - http://bayou.io/draft/cookie。 domain.html
总而言之，关于 Cookie 域要遵循的规则：
Cookie 的原始域是原始请求的域。
如果源域是IP，则不能设置cookie的域属性。
如果未设置cookie的domain属性，则该cookie仅适用于其原始域。
如果设置了 cookie 的域属性，
由此可见，cookie 始终适用于其原始域。
cookie 域不应该有一个前导点，如
.foo.com- 只需使用foo.com作为示例，
xyzcom可以设置自身或父级的 Cookie 域 -xyzcom、yzcom、z.com。 但com不行，它是公共后缀。yzcom的cookie适用于yzcom、xyzcom、axyzcom等。公共后缀示例 - <代码>com、
edu、uk、co.uk、blogspot.com、compute.amazonaws.comThe previous answers are a little outdated.
RFC 6265 was published in 2011, based on the browser consensus at that time.
Since then, there has been some complication with public suffix domains. I've written an article explaining the current situation - http://bayou.io/draft/cookie.domain.html
To summarize, rules to follow regarding cookie domain:
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,
It can be derived that a cookie is always applicable to its origin domain.
The cookie domain should not have a leading dot, as in
.foo.com- simply usefoo.comAs an example,
x.y.z.comcan set a cookie domain to itself or parents -x.y.z.com,y.z.com,z.com. But notcom, which is a public suffix.y.z.comis applicable toy.z.com,x.y.z.com,a.x.y.z.cometc.Examples of public suffixes -
com,edu,uk,co.uk,blogspot.com,compute.amazonaws.com我在 2019 年最新的 Chrome、Firefox、Safari 中测试了所有案例。
对已添加的响应：
I tested all the cases in the latest Chrome, Firefox, Safari in 2019.
Response to Added:
要获得广泛的覆盖范围，请查看 RFC2965 的内容。 当然，这并不一定意味着所有浏览器的行为方式完全相同。
但是，一般来说，如果 cookie 中未指定任何内容，则默认路径的规则是 Set-Cookie 标头到达的 URL 中的路径。 同样，域的默认值是 Set-Cookie 到达的 URL 中的完整主机名。
域的匹配规则要求 cookie 域与发出请求的主机相匹配。 cookie 可以通过 include * 指定更广泛的域匹配。 在 Set-Cookie 的域属性中（这一区域浏览器可能会有所不同）。 匹配路径（假设域匹配）很简单，请求的路径必须位于 cookie 上指定的路径内。 通常，会话 cookie 使用 path=/ 或 path=/applicationName/ 设置，因此 cookie 可用于进入应用程序的所有请求。
__Response to Added:__
*我现在无法对此进行测试，但我有一个预感，至少 IE7/6 会将路径example.com视为。 example.com。For an extensive coverage review the contents of RFC2965. Of course that doesn't necessarily mean that all browsers behave exactly the same way.
However in general the rule for default Path if none specified in the cookie is the path in the URL from which the Set-Cookie header arrived. Similarly the default for the Domain is the full host name in the URL from which the Set-Cookie arrived.
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:__
*I'm unable to test this right now but I have an inkling that at least IE7/6 would treat the pathexample.comas if it were.example.com.此问题的最后一个（确切地说是第三个）RFC 是 RFC-6265（废弃 RFC-2965，进而废弃 RFC-2109）。
据此如果服务器省略了Domain属性，用户代理只会将 cookie 返回到原始服务器（给定资源所在的服务器）。 但这也是警告，一些现有的用户代理将不存在的域属性视为域属性存在并包含当前主机名（例如，如果 example.com 返回没有 Domain 属性的 Set-Cookie 标头，这些用户代理将错误地将 cookie 发送到 www.example.com以及）。
当Domain属性被指定时，它将被视为完整的域名（如果属性中有前导点，它将被忽略）。 服务器应该与属性中指定的域匹配（具有完全相同的域名或者是其子域）才能获取此 cookie。 更准确地说，此处指定。
因此，例如：
Domain=.example.com相当于Domain=example.comDomain=www.example.com将关闭www4.example.com 的方式PS：域属性中的尾随逗号将导致用户代理忽略该属性 =(
The last (third to be exactly) RFC for this issue is RFC-6265 (Obsoletes RFC-2965 that in turn obsoletes RFC-2109).
According to it if the server omits the Domain attribute, the user agent will return the cookie only to the origin server (the server on which a given resource resides). But it's also warning that some existing user agents treat an absent Domain attribute as if the Domain attribute were present and contained the current host name (For example, if example.com returns a Set-Cookie header without a Domain attribute, these user agents will erroneously send the cookie to www.example.com as well).
When the Domain attribute have been specified, it will be treated as complete domain name (if there is the leading dot in attribute it will be ignored). Server should match the domain specified in attribute (have exactly the same domain name or to be a subdomain of it) to get this cookie. More accurately it specified here.
So, for example:
Domain=.example.comis equivalent toDomain=example.comDomain=www.example.comwill close the way for www4.example.comPS: trailing comma in Domain attribute will cause the user agent to ignore the attribute =(
众所周知，RFC 并不反映现实。
最好检查 draft-ietf-httpstate-cookie，工作正在进行中。
The RFCs are known not to reflect reality.
Better check draft-ietf-httpstate-cookie, work in progress.
有一些规则确定浏览器是否接受 Set-header 响应标头（服务器端 cookie 写入），使用 Javascript 设置 cookie 的规则/解释略有不同（我还没有测试 VBScript）。
然后有一些规则确定浏览器是否随页面请求一起发送 cookie。
主要浏览器引擎之间处理域匹配的方式以及如何解释路径值中的参数之间存在差异。 您可以在文章 如何不同浏览器以不同方式处理 Cookie
There are rules that determine whether a browser will accept the Set-header response header (server-side cookie writing), a slightly different rules/interpretations for cookie set using Javascript (I haven't tested VBScript).
Then there are rules that determine whether the browser will send a cookie along with the page request.
There are differences between the major browser engines how domain matches are handled, and how parameters in path values are interpreted. You can find some empirical evidence in the article How Different Browsers Handle Cookies Differently
不可以，但
example.com.fr可以为example2.com.fr设置 cookie。 Firefox 通过维护 TLD 列表来防止这种情况的发生： http://securitylabs.websense.com /content/Blogs/3108.aspx显然，Internet Explorer 不允许两个字母的域设置 cookie，我想这解释了为什么
o2.ie简单地重定向到o2online。即。 我经常想知道这一点。No, but
example.com.frmay be able to set a cookie forexample2.com.fr. Firefox protects against this by maintaining a list of TLDs: http://securitylabs.websense.com/content/Blogs/3108.aspxApparently Internet Explorer doesn't allow two-letter domains to set cookies, which I suppose explains why
o2.iesimply redirects too2online.ie. I'd often wondered that.我很惊讶地读到了关于拒绝 cookie 的第 3.3.2 节：
https://www.rfc-editor .org/rfc/rfc2965
这表示浏览器应该拒绝来自 xyzcom 且域为 .z.com 的 cookie，因为“xy”包含一个点。 因此，除非我误解了 RFC 和/或上述问题，否则可能会添加问题：
Will a cookie for .example.com be available for www.yyy.example.com？ 不会。
源服务器 www.yyy.example.com 设置的 cookie，域名为 .example。 com，用户代理是否已将其值发送到 xxx.example.com？ 不。
I was surprised to read section 3.3.2 about rejecting cookies:
https://www.rfc-editor.org/rfc/rfc2965
That says that a browser should reject a cookie from x.y.z.com with domain .z.com, because 'x.y' contains a dot. So, unless I am misinterpreting the RFC and/or the questions above, there could be questions added:
Will a cookie for .example.com be available for www.yyy.example.com? No.
Will a cookie set by origin server www.yyy.example.com, with domain .example.com, have it's value sent by the user agent to xxx.example.com? No.