众所周知，rfc并不能反映现实。

最好检查draft-ietf-httpstate-cookie，工作正在进行中。

要获得广泛的覆盖，请查看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是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属性中的尾随逗号会导致用户代理忽略属性=(

我很惊讶地读到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 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)。

众所周知，rfc并不能反映现实。

最好检查draft-ietf-httpstate-cookie，工作正在进行中。