我简直不敢相信这一点竟然如此难以确定。
即使阅读了 RFC，我仍然不清楚 subdomain.example.com 的服务器是否可以设置可由 example.com 读取的 cookie。
subdomain.example.com 可以设置一个域属性为 .example.com 的 cookie。RFC 2965 似乎明确指出，这样的 cookie 不会发送到 example.com，但同样指出，如果您设置 Domain=example.com，则会在前面添加一个点，就像您说 .example.com 一样。综合起来，这似乎表明，如果 example.com 返回一个域属性为 Domain=example.com 的 cookie，它不会取回该 cookie！这不可能是对的。
有人能解释一下规则到底是什么吗？
答案1
引用同一篇文章RFC2109你读：
* 来自请求主机 x.foo.com 的 Domain=.foo.com 的 Set-Cookie 将会
被接受。
因此subdomain.example.com可以为 设置一个 cookie .example.com。到目前为止一切顺利。
以下规则适用于选择适用的 cookie 值
在用户代理拥有的所有 cookie 中。
域选择
源服务器的完全限定主机名必须与域匹配
Cookie 的 Domain 属性
那么我们的域名匹配吗？
* A 是 FQDN 字符串，形式为 NB，其中 N 是非空名称
字符串，B 的形式为 .B'，而 B' 是 FQDN 字符串。（因此，xycom
域名匹配 .y.com 但不匹配 y.com。）
但现在根据定义example.com不会进行域匹配。但（或域中的任何其他“非空名称”）会。理论上，此 RFC 已被淘汰.example.comwww.example.comRFC2965Set-Cookie2，它规定了在操作中强制使用域名的前导点。
正如@Tony 所说，更重要的是现实世界。要了解实际用户代理正在做什么，请参阅
和
为了了解实际站点正在做什么，请尝试wget使用--save-cookies、--load-cookies和--debug来查看发生了什么。
你可能会发现，事实上大多数网站都使用了Set-Cookie旧版 RFC 规范中的某种组合，其中隐式地没有前导点（因为twitter.com或设置域值（以点开头）并重定向到服务器，如www.example.com（如google.com做）。
答案2
如果浏览器实现RFC 6265，任何现代浏览器此时都应该这样做，那么为设置的 cookie.example.com将忽略前导点（第 5.2.3 节），然后该 cookie 将被发送到裸域和所有子域。
如果您有大量来自旧版浏览器的流量，请不要依赖此行为；此 RFC 仅可追溯到 2011 年。
答案3
这应该是不可能的。但是，正如你所说，由于这不是一个广泛记录的标准，所以这取决于你使用的软件。
大多数现代浏览器都遵循已定义的“网络安全模型”。该模型有效地控制了浏览器在安全方面的行为，例如 Cookie（特别是它们将如何发送回任何给定网站）。该模型还规定“浏览器不会向未设置 Cookie 的域名发送 Cookie”。
话虽如此，domain.com 应该能够为 js.domain.com 设置 cookie。但是，js.domain.com 只能为自己设置 cookie。但这完全取决于您使用的浏览器。