为什么foo.example.com可以为example.com设置cookies？

Question

从文档和this link中，我已经知道foo.example.com可以通过在example.com报头中发送带有Domain = example.com的响应来为Set-Cookie设置cookies。但是为什么这是允许的呢？

例如，事实是，服务器(比如foo.example.com)不能为它的兄弟服务器(比如bar.example.com)或比它低的域名(也称为“它的孩子”，比如ide.foo.example.com)设置cookies，但是它可以为比它高的域名(也称为“它的父母”，在本例中是example.com )设置cookies。

让我把这个问题的陈述放到现实世界中，让它变得更加清晰。就像Google App Engine上的应用程序一样，foo.appspot.com显然不能为bar.appspot.com设置cookie，因为它们是两个不同的应用程序，它们不应该影响彼此的行为。但是，为什么允许foo.appspot.com通过在其响应头中发送Domain = appspot.com来为appspot.com设置cookies？通过这样做，foo.appspot.com应用程序实际上可以影响其他应用程序在Google app Engine上的行为，因为浏览器将在访问bar.appspot.com时发送此cookie，其域名是appspot.com的子项。

我从Udacity上的Web开发课程中学到了所有这些关于cookies的东西。但我真的对这个问题感到困惑。有人能帮我解释一下吗？提前谢谢。:-)

Answer 1

您提供的链接非常过时。太糟糕了，人们在谷歌上搜索"cookie domain“会首先找到它。

我应该写一个更好的；但现在，为了快速回答你的问题-它是关于“公共后缀”域的。

服务器"example.com“可以为"com”设置cookie吗？不，因为"com“是一个公共后缀。

"foo.co.uk“可以为"co.uk”设置cookie吗？不，因为"co.uk“是一个公共后缀。

碰巧"appspot.com“也是一个公共后缀，所以"foo.appspot.com”不能用domain="appspot.com“设置cookie。(它可以，但浏览器会拒绝它)

不幸的是，没有算法来确定哪个是公共后缀。所有公共后缀列表在https://publicsuffix.org/中手动维护