浏览器Cookie域如何工作?

由于我得到奇怪的域名/子域cookie的问题,我想知道浏览器如何处理cookie。 如果他们以不同的方式来做,那么知道这些差异也是很好的。

换句话说 – 当浏览器接收到一个cookie时,该cookie可能会有一个域名和一个附加的路径。 或者不,在这种情况下,浏览器可能会替代一些默认值。 问题1:他们是什么?

之后,浏览器即将发出请求时,它会检查其Cookie并过滤出应该发送的请求。 它通过将它们与请求路径和域相匹配来实现。 问题2:匹配规则是什么?


添加:

我问这个问题的原因是因为我对一些边缘案例感兴趣。 喜欢:

  • www.example.com .example.com Cookie是否可用?
  • .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.comexample.com ;
  • 它可以通过www.example.comexample.com访问。

尽管现在应该定义cookie的RFC 2965 ( Set-Cookie2 ,已经过时了RFC 2109 ),但是大多数浏览器并不完全支持,只是遵从Netscape的原始规范 。

Domain属性值和有效域之间有区别:前者取自Set-Cookie头域,后者是该属性值的解释。 根据RFC 2965,以下内容应该适用:

  • 如果Set-Cookie头域没有 属性,则有效域是请求的域。
  • 如果存在Domain属性,则其值将被用作有效域(如果值不以a开头,则将由客户端添加)。

有了有效的域名,它也必须域名匹配当前请求的域名被设置; 否则cookie会被修改。 同样的规则适用于选择在请求中发送的cookie。


将这些知识映射到您的问题上,应该适用以下内容:

要设置和读取http://www.example.comexample.com的cookie,请分别将其设置为.www.example.com.example.com 。 但是,第一个( .www.example.com )只能在该域下的其他域(例如foo.www.example.combar.www.example.com )访问,其中.example.com也可以被任何example.com以下的其他域(例如foo.example.combar.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域不应该有一个前导点,如.foo.com – 只需使用foo.com

举个例子,

  • xyzcom可以为自己或父母设置一个cookie域 – xyzcomyzcomz.com 。 但不是com ,这是一个公共后缀。
  • 域名为yzcom的cookie适用于yzcomxyzcomaxyzcom等。

公共后缀的示例 – comeduukco.ukblogspot.comcompute.amazonaws.com

广泛的覆盖面审查RFC2965的内容。 当然这并不意味着所有浏览器的行为都是完全相同的。

但是,一般来说,如果cookie中没有指定默认路径的规则,则是Set-Cookie头部到达的URL中的路径。 同样,Domain的默认值是Set-Cookie到达的URL中的完整主机名。

域的匹配规则要求Cookie域与请求所在的主机相匹配。 Cookie可以通过include *指定更广泛的域名匹配。 在Set-Cookie的域属性中(这个浏览器可能会有所不同)。 匹配路径(假设域匹配)是一个简单的问题,请求的路径必须在cookie中指定的路径内。 通常,会话cookie设置为path = /或path = / applicationName /,因此cookie可用于应用程序中的所有请求。


回应添加:

*我现在无法对此进行测试,但我有一个暗示,至少IE7 / 6会将example.com路径视为.example.com

最后一个(正好是第三个)RFC是这个问题的RFC-6265(废弃了RFC-2965,而废弃了RFC-2109)。

据此,如果服务器省略了域属性,则用户代理将仅将cookie返回给原始服务器 (给定资源驻留的服务器)。 但是,它也警告一些现有的用户代理将缺少的域属性视为存在域属性,并且包含当前主机名(例如,如果example.com返回没有域属性的Set-Cookie头,这些用户代理将错误地发送cookie到www.example.com)。

当Domain属性被指定时,它将被视为完整的域名(如果有属性中的前导点,它将被忽略)。 服务器应该匹配属性中指定的域(具有完全相同的域名或作为它的子域名)来获取此cookie。 在这里指定更准确。

所以,例如:

  • Cookie属性Domain=.example.com等同于Domain=example.com
  • 具有这种域属性的cookie将用于example.comhttp://www.example.com
  • 具有此类域名属性的cookie将不可用于another-example.com
  • 指定Cookie属性,如Domain=www.example.com将关闭www4.example.com的方式

PS:域属性中的尾随逗号将导致用户代理忽略属性=(

有一些规则可以决定浏览器是否接受Set-header响应头(服务器端cookie写入),使用Javascript(我还没有测试过VBScript)对cookie设置稍微不同的规则/解释。

然后有一些规则可以决定浏览器是否会随页面请求一起发送一个cookie。

主要浏览器引擎如何处理域匹配以及如何解释路径值中的参数存在差异。 在“ 不同浏览器如何处理饼干 ”一文中,您可以找到一些经验性证据

RFC已知不反映现实。

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

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 。 我经常想知道。

我很惊讶地阅读关于拒绝cookies的第3.3.2节:

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

这就是说浏览器应该从域名为.z.com的xyzcom中拒绝一个cookie,因为'xy'包含一个点。 所以,除非我误解了RFC和/或上面的问题,否则可能会添加一些问题:

http://www.yyy.example.com是否会提供.example.com的cookie?; 没有。

将原始服务器www.yyy.example.com设置的cookie设置为域.example.com,是否将用户代理发送给xxx.example.com的值? 没有。