Java中的Cookie的意思和用途是啥？

Posted 2023-05-16

参考技术A cookie就是把一些信息存放到浏览器能够读取的到的地方，一般为ie的临时目录\\x0d\\x0a\\x0d\\x0a可以通过js或者java来读取自己域内的cookie信息\\x0d\\x0a\\x0d\\x0a存放在cookie的好处是前后台都可以读取，速度相对比较快\\x0d\\x0a\\x0d\\x0a用途：一些不常改变的信息，可以保存在cookie里，这样就可以减少读取数据库，降低数据库的压力

cookie 域中的点前缀是啥意思？

【中文标题】cookie 域中的点前缀是啥意思？

【英文标题】：What does the dot prefix in the cookie domain mean?cookie 域中的点前缀是什么意思？

【发布时间】：2012-03-25 23:15:15

【问题描述】：

local.test.com 和 .local.test.com 有什么区别？屏幕截图来自 Chrome。

【问题讨论】：

***.com/questions/2285010/php-setcookie-domain

2016 年 9 月 26 日 16:44 来自 user2864740 的评论 - 链接已失效，显然 erik.io 域已传递给另一个用户或域注册商。

【参考方案1】：

来自The definitive guide to cookie domains and why a www-prefix makes your website safer的文章：

结论

虽然定义有些不同，我们可以简化一下 对于这些实现中的任何一个：

当cookie中没有设置域时，cookie应该只匹配 请求的确切主机名。 [注意：这与返回带有不带点的域的 Set-Cookie 不同！] 没有子域，没有部分匹配。 这意味着根本不包括域属性——它是无效的 设置一个空域属性。不幸的是，Internet Explorer 似乎将此视为主机名以及任何子域。

在 cookie 中设置域时，安全的选择是将其放在前面 一个点，比如 .erik.io。 cookie 将与所有子域匹配。

设置一个不带点的 cookie 域，如 erik.io，是 在 RFC 2109 实现中无效，并且会产生相同的结果 行为与其他实现上的前一个点一样。 无法将 cookie 限制为特定的明确设置的域， 不包含子域。

其他有价值的观察：

在所有 RFC 中，指定的 cookie 域必须与当前主机匹配 名称，按正常匹配。为 www.erik.io 设置一个 cookie 来自 erik.io 的响应无效，作为带有域的 cookie www.erik.io 与 erik.io 不匹配，前者更具体。

在 RFC 6265 中，域在解析 Set-Cookie 标头。

【参考方案2】：

“.local.test.com”中的前导点就是 chrome 如何查看设置了“Domain=local.test.com”（或“Domain=.local.test.com”的 cookie，即一样）。

不带“Domain=something”的 Set-Cookie 定义会查看不带前导点的域 (=host)。

因此，chrome 中的前导点并不反映服务器是否使用了前导点，而是该 cookie 在其定义中是否具有来自服务器的“Domain=something”。 （如果有，cookie 也会被发送到子域）。

至少这是我的测试结果。 Chrome 应该使其更易于阅读，例如查看定义 cookie 的确切字符串以及接收时间。

【参考方案3】：

前面的点表示 cookie 对子域也有效；然而最近的 HTTP 规范 (RFC 6265) 改变了这个规则，所以现代浏览器不应该关心前导点。实现已弃用的 RFC 2109 的旧浏览器可能需要该点。

RFC 6265 section 4.1.2.3

例如，如果 Domain 属性的值为“example.com”，当向 example.com、www.example.com 和 www.corp.example.com 发出 HTTP 请求时，用户代理将在 Cookie 标头中包含 cookie。 （请注意，如果存在前导 %x2E（“.”），即使该字符是不允许的，也会被忽略，但如果存在尾随 %x2E（“.”），将导致用户代理忽略该属性。 )

【讨论】：

RFC 的日期为 2011 年 4 月。IE8 和 IE9 最初都是在该日期之前发布的，遗憾的是 - 仍在使用。所以我最好的猜测（没有尝试）是他们需要前导点。有人知道估计有多少浏览器仍在旧 RFC 上运行？

erik.io/blog/2014/03/04/definitive-guide-to-cookie-domains 建议在希望包含子域时使用前导点以获得最佳兼容性。这种兼容性要求只会继续降低。 （6255 不需要，但需要，最终结果与 2109 相同。）

【参考方案4】：

local.test.com 将用于域，而.local.test.com 也将用于子域。

【讨论】：

所以local.test.com 将不适用于x.local.test.com，但.local.test.com 同时适用于local.test.com 和x.local.test.com？

我认为这是不正确的。 Cookie 与任何和所有下游子域共享，带有或不带有点。您可以将子域视为从其父域“继承”cookie。因此，在 example.com 上设置 cookie 会将其设置在 blog.example.com 和 my.blog.example.com 上。在 blog.example.com 上设置 cookie 会将其设置在 this.is.my.blog.example.com 和其间的每个子域上。但是，就像继承一样，反过来是不正确的。在 blog.example.com 上设置 cookie 不会在 example.com 上设置。

也就是说，您可以通过根本不设置 cookie 的域（或设置为空字符串）来将 cookie 限制为仅主机。奇怪的是，这只会为主机（example.com）而不是它的任何子域设置 cookie。

根据另一个答案进行澄清，点 used 有所作为，但现在没有了。 cookie 将被发送到指定域的任何子域，带或不带前导点。真正控制它是否传递给子域的是 是否 您是否在 cookie 上设置域。如果您根本没有设置域，那么 cookie 只会被发送到发出它的确切域。它永远不会被发送到不太具体的父域（例如，“local.test.com”不会包含在对“test.com”的请求中），并且如果您设置了域值，它只会被发送到匹配的子域。

@Triynko，当您要更新 cookie 时，点会有所不同。我还没有设法隔离所有规则，但我看到结果会根据是否存在前导点而有所不同，而且它不是直截了当的。它的工作方式因浏览器而异，并且并非都是直观的。控制 cookiename 在浏览器上是否有前导点并不是我做过的最简单的编程任务。