是否允许 HTTP 请求 URI 包含“..”段？
根据 RFC 2616 第 5.1.2 节，它们可以引用绝对 URI 或绝对路径（该部分中的其他选项与此问题无关）。
RFC 3986 中描述了绝对 URI 和绝对路径的含义，其中还描述了一种规范化路径的算法（包括删除单点和双点元素）。
但是，我找不到符合 RFC 的请求 URI 是否可以包含“..”段的确切规范 - 它们是否允许在绝对路径/URI 中，服务器是否必须规范化此类 URI？还是由客户决定？
“位置：”响应标头有什么不同吗？根据规范，它们只能包含绝对 URI，但这是否包括“..”部分？在请求引用的资源之前，客户端是否也必须对这些进行规范化？
澄清一下，我知道像../foo 这样的URI 在这些情况下是非法的，但是http://example.com/../foo 呢？这是一个有效的绝对 URI 吗？
我目前正在将客户端重定向到此类 URI，并想知道这是否符合规范。
【问题讨论】：
如果你想“知道它是否符合规范”，你为什么不简单地参考相关规范呢？
RFC 3986 Section 5.2 非常清楚应该如何解析 URI 点段：
本节描述了一种用于转换 URI 引用的算法 可能与解析组件中的给定基本 URI 相关 参考的目标。然后可以重新组合组件，如 在第 5.3 节中描述，以形成目标 URI。这个算法 提供可用于测试输出的明确结果 其他实现。应用程序可以实现相对引用 使用其他算法解决，前提是结果 匹配这个将给出的内容。
例如，如果您遵循Location: 标头，则规范化和解决无效的相对路径通常是谨慎的做法（Location: 标头应该是绝对 URI）。在这些情况下，您绝对应该按照 RFC 3986 的说明根据您的基本 URI 解析这些路径。
您是否应该在 URI 中到处传递点段？如果您可以提供帮助，可能不会，因为您依赖其他人正确实施规范。但是传递带有点段的 URI 是否违反了 URI 规范？ 否。
【讨论】：
从语法上讲，http://example.com/../foo 是一个有效的 URI。
服务器如何解释 URI 是另一回事。出于明显的安全原因，服务器必须非常小心如何将 URI 转换为文件路径。通常，服务器要么删除.. 段，要么进行某种后处理以确保文件路径位于文档根目录内。
【讨论】：
（感谢您在一个充满绝望的公众困惑的话题中提出了一个伟大而清晰的问题，由神秘的规范和令人惊讶的微妙之处助长！）
...http://example.com/../foo 呢？这是一个有效的绝对 URI 吗？
（因此，当我尝试向服务器提供类似的东西时，我得到了服务器应有的“400 Bad request”响应。）
/root/../foo：@rdlowrey 的答案是正确的：更好地将它们标准化你自己，如果可以的话。（再次举个例子，当浏览器发送到同一台服务器时，我的代理在运行良好的页面上失败了，这会更加努力地规范化点部分，而不是依赖服务器做同样的事情.)
但是，我找不到 RFC 的确切规范 符合要求的请求 URI 可以包含“..”段 - 它们是否允许在 绝对路径/URI，服务器是否必须规范化此类 URI？ 还是由客户决定？
【讨论】：