问题标签 [rfc6265]

我正在寻找符合 rfc 6265 的浏览器列表。我问谷歌先生，显然这不是一个简单的答案。

谢谢！

我正在寻找一种简单的方法来检查给定的 cookie 域域是否与给定的主机名匹配。

为此，我将实施RFC 6265 第 5.1.3 节中定义的域匹配条件。

定义的两个匹配条件中的第二个是一个多部分条件，其中应用了三个子条件：

以下所有条件均成立：

• 域字符串是字符串的后缀。
• 未包含在域字符串中的字符串的最后一个字符是 %x2E (".") 字符。
• 该字符串是主机名（即，不是 IP 地址）。

为清楚起见，当上面引用的文本指的是“字符串”时，它指的是 cookie 的域值，而当上面引用的文本指的是“域名”时，它指的是 cookie 所指向的主机的域名可能会被发送。

在这三个子条件中，第一个和第三个是很清楚的。我感到困惑的是第二个的措辞。

我知道“example.com”的cookie域仅匹配“example.com”，而“.example.com”的cookie域匹配“<anything>.example.com”。如果提到这个广泛的子域匹配概念，我最好的猜测是高于第二个子条件，但是考虑到我不能确定的措辞。

有没有人能够将第二个子条件翻译成简单的技术英语？

我读过 RFC 2109 需要前导点，而 RFC 6265 忽略前导点。

对于在 JavaScript 中跨域和子域共享的 cookie，cookie 可以具有字段 ;domain=.domain 或 ;domain=domain

在 Mozilla 关于 cookie 的文档中，它说：“与早期的规范相反，域名中的前导点被忽略。如果指定了域，则始终包含子域。” https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie

那么最佳实践是什么？是否包括前导点符号？也许包括点允许使用旧标准的浏览器向后兼容。

目前我已经阅读了 RCF 6265 第4.1.1章关于 set-cookie 标头的语法。在 4.1.1 正文中：

语法列表中有一个条目：

在我看来，这意味着可以将 JWT 保存在 Cookie 中，但是当我继续阅读时，我没有找到有关该字段的文档。同样在维基百科上我没有找到这个字段。

我的观点是错的还是？或者是否可以将 JWT（JWE、JWS）保存在 cookie 中？因为在 PHP set_cookie()-Method上我也找不到这个“令牌”字段。还是将令牌保存在 cookie 中并将 JWT 设置为 set_cookie()-Method 的值也是最佳做法？

我在 ZAP 脚本中遇到问题。

我尝试使用 Zest 创建登录脚本。除了其中两个之外，大多数请求都有效。我发现重新发送请求时有些问题（状态码为 200），所以我代理链式 Zap 并在脚本请求中看到有多个 cookie 标头。

原来的 ：

重新发送：

第一个请求不符合 RFC 6265

5.4. Cookie 标头

用户代理在 Cookie HTTP 请求标头中包含存储的 cookie。

当用户代理生成一个 HTTP 请求时，用户代理不能附加多个 Cookie 头字段。

就我而言，服务器强制执行此操作，并且仅解析第一个 cookie。

那么，我的问题是，当 zap 在 zest 脚本期间添加 cookie 时，ZAP 中是否有一种方法可以将 cookie 折叠成一个？

我正在编写一个 PHP 类来处理/解析Cookie和Set-CookieHTTP 标头，以便在我的自定义用户代理（爬虫、刮板、机器人等）中使用它，并且在测试它时我发现它的行为与 Firefox 不同他们处理标题中的Path属性的方式。Set-Cookie我回到RFC 6265，我是对的

###如何重现？在任何 PHP 文件中设置此行并请求它

现在使用 Firefox 请求/bar，您将看到 Firefox 正在发送 cookie，而/bar/根据规范它应该只发送到或更长的路径！

###规格是什么？

我将引用RFC 6265 5.1.4 Paths and Path-Match中的相关部分

如果至少满足以下条件之一，则请求路径路径匹配给定的 cookie 路径：

o cookie-path 和 request-path 是相同的。

o cookie-path 是 request-path 的前缀，cookie-path 的最后一个字符是 %x2F ("/")。

o cookie-path 是 request-path 的前缀，并且不包含在 cookie-path 中的 request-path 的第一个字符是 %x2F ("/") 字符。

在这种情况下，请求路径/bar和 cookie 路径/bar/不匹配

###谷歌浏览器怎么样？

谷歌浏览器不会将 cookie 发送到/bar

我的问题

谁是对的？铬合金 ？还是火狐？

###额外细节：

我在 Linux 上的 Firefox 66.0.4 和 Chrome 版本 76.0.3809.132 Linux 上进行了测试

这是我在课堂上使用的相关功能

这是我为 Firefox找到的第二个问题，但它仍然是我最喜欢的浏览器 :)

感谢@fendall 对有关 RFC 的评论，我跟踪了与此问题相关的 RFC

• 1997 年 2 月RFC 2109历史。被淘汰
• 2000 年 10 月RFC 2965历史。被淘汰
• 2011 年 4 月RFC 6265提议的标准，如果获得批准，将被淘汰
• 2017 年 8 月草案-ietf-httpbis-rfc6265bis-02互联网草案

MDN Set-Cookie 文档使用了RFC 6265和draft-ietf-httpbis-rfc6265bis-02的规范，并且在“路径和路径匹配”部分中这两个规范几乎相同。（我在问题中引用的部分）

我向 Bugzilla 报告了一个错误https://bugzilla.mozilla.org/show_bug.cgi?id=1579552

我尝试在 Python 中使用正则表达式解析 set-cookie 标头。对于 set-cookie 标头，我阅读了描述如何构建 set-cookie 标头的RFC 6265 第 4.1 节。我尝试从规范构建一个正则表达式，这是我目前的状态：

domain=...我在set-cookie 标头（

但我之前的代码工作也完全没有预料到。例如这个 set-cookie 标头

包括 4 个 cookie（VISITOR_INFO1_LIVE两次GPS和YSC），但我的正则表达式仅捕获 3 个 cookie（YSC缺少 cookie）。我在https://regex101.com/上进行了测试

稍后我会解析许多 set-cookie 标头以获取 cookie 的名称（或在 RFC 中调用该 cookie 名称）。

感谢帮助！

作为从网络上抓取数据的业余项目的一部分，我正在写一些东西来抽象出对 cookie 的处理。我已经找到了RFC 6265，它定义了应该如何处理 cookie，但是我阅读得越频繁、越仔细，我就越感到困惑。

1. 请有人确认这是定义所需内容的适当文件。
2. 该文档的第 5.3 节列出了 cookie 应存储的字段。是否有任何地方提供一些 Cookie 示例的来源：标头以及应由定义的 cookie 存储的值？
3. 我对文档第 5.1.4 节中描述如何“计算 cookie 的默认路径”的算法感到有些困惑。在阅读了互联网上的各种资料后，我假设如果标头中没有指定 PATH，则默认路径应该存储在 cookie 中，并且第 5.1.4 节中提到的 request-uri 是资源的 id收到 Cookie: 标头时返回。请问有人可以确认或纠正我吗？
4. 我对第 5.1.4 节的默认路径算法感到更加困惑，该算​​法讨论了如何处理不以“/”字符开头的 uri-path，因为rfc1738 的最后一段，第 3.1 节明确声明主机（或端口）和 url-path 之间的“/”不是 url-path 的一部分”。（rfc1738 的标头说它已被 rfc4248 和 rfc4266 淘汰，但由于它们分别描述了 telnet 和 gopher 方案的 URL，而我只对 http(s) URL 感兴趣，我相信我可以放心地忽略它们.) 据我所见，如果没有 PATH 属性的 cookie 与具有 http/https 方案的资源一起发送，则 cookie 会将其路径属性设置为“/”。如果具有 id 的资源使用稍后请求http / https方案，请求路径也不会以“/”开头，因此cookie永远不会路径匹配并且不会包含在请求中。这看起来很荒谬。请有人帮我看看我是什么误会了吗？

我假设域匹配规则的重点是让站点可以指定只应发送回自身或其子域的 cookie，但我不太确定路径匹配规则应该做什么，也许如果有人可以提供一个模糊但可以理解的一句话描述，我也许可以自己解决这个困惑？

非常感谢。