在路径 /a/b/c 中设置的 cookie 的默认 cookie 路径是什么？

Question

RFC 6265 提供以下algorithm 用于计算在Path 属性不存在的情况下cookie 应适用的默认路径：

用户代理必须使用与以下等效的算法 计算 cookie 的默认路径的算法：

1. 让 uri-path 成为请求 uri 的路径部分，如果这样 部分存在（否则为空）。例如，如果 request-uri 只包含一个路径（和可选的查询字符串）， 那么 uri-path 就是那个路径（没有 %x3F ("?") 字符 或查询字符串），并且如果请求 uri 包含完整的 absoluteURI，uri-path 是该 URI 的路径组件。

2. 如果 uri-path 为空或者如果 uri- 路径不是 %x2F ("/") 字符，输出 %x2F ("/") 并跳过 剩下的步骤。

3. 如果 uri-path 包含不超过一个 %x2F ("/") 字符， 输出 %x2F ("/") 并跳过剩下的步骤。

4. 从第一个字符开始输出uri-path的字符 到但不包括最右边的 %x2F ("/")。

让我们以从https://example.com/a/b/c 接收没有Path 属性的Set-Cookie 标头为例。在这种情况下，uri-path 是 /a/b/c。没有尾部斜杠，因此，如果我正确解释规范，“最右边”的斜杠不是c 之前的斜杠，因此cookie-path 是/a/b？

另一种询问方式是，如果现代的、符合规范的浏览器从 https://example.com/a/b/c 接收到没有 Path 属性（或除 name=value 之外的任何属性）的 cookie，该 cookie 是否应该以对https://example.com/a/b的后续请求？

Answer 1

没有尾随斜杠，因此，如果我正确解释规范，“最右边”的斜杠不是 c 之前的斜杠，因此 cookie 路径是 a/b？

几乎。从 1 开始，uri-path 将变为 /a/b/c。 2和3不适用。从 4 开始，输出将是 /a/b，包括前导 /。

另一种询问方式是，现代、符合规范的浏览器是否收到了 cookie

如果您的意思是 实际 浏览器，这不是 完全 同一个问题；你找到不同的解释了吗？

与规范仍有分歧，the web-platform-tests dashboard for cookies/path 之类的资源可能是确认现代浏览器行为的更好资源。

但是，根据规范回答：

收到一个没有 Path 属性的 cookie ... 来自https://example.com/a/b/c，该cookie 是否应该在后续请求中发送到https://example.com/a/b？

是的，因为 5.1.4 中的算法意味着 cookie 的 default-path 是 /a/b，而这个路径匹配 /a/b 因为

cookie-path 和 request-path 相同。