HTTP请求URI是否允许包含“..”段？
根据RFC 2616第5.1.2节，它们可以引用绝对URI或绝对路径（该部分中的其他选项与此问题无关）。
RFC 3986中描述了绝对URI和绝对路径的含义，它还描述了一种规范化路径的算法（包括删除单点和双点元素）。
但是，我找不到确切规范RFC符合请求URI是否可以包含“..”段 - 它们是否允许在绝对路径/ URI中，并且服务器是否必须规范化此类URI？或者这取决于客户？
“位置：”响应标头有什么区别吗？根据规范，它们只能包含绝对URI，但这包括“..”部分吗？在请求引用的资源之前，客户端是否也必须将其标准化？
为了澄清，我知道像../foo这样的URI在这些情况下是非法的，但是http://example.com/../foo呢？这是一个有效的绝对URI吗？
我目前正在将客户端重定向到这样的URI，并想知道这是否符合规范。
答案 0 :(得分：4)
如果您想“知道这是否符合规格，”为什么不简单地参考相关规范？
RFC 3986 Section 5.2非常清楚如何解析URI点片段：
本节介绍用于转换URI引用的算法 可能与解析组件中的给定基URI相关 引用的目标。然后可以重新组合组件，如 在5.3节中描述，以形成目标URI。这个算法 提供可用于测试输出的确定结果 其他实现。应用可以实现相对参考 通过使用其他算法的分辨率，提供结果 匹配这个给出的。
例如，如果您遵循Location:标头，则通常谨慎地规范化并解决无效的相对路径（Location:标头应该是绝对URI）。在这些情况下，您应该完全按照RFC 3986的说明来解决针对您的基URI的路径。
你是否应该遍布URI中的点段？可能不是，如果你可以帮助它，因为你依赖其他人正确实施规范。但传递带点分段的URI是否违反了URI规范？ 否
答案 1 :(得分：0)
从语法上讲，http://example.com/../foo是一个有效的URI。
服务器如何解释该URI是另一回事。出于明显的安全原因，服务器必须非常小心如何将URI转换为文件路径。通常，服务器将删除..段，或进行某种后处理以确保文件路径位于文档根目录中。
答案 2 :(得分：0)
（感谢您在一个充满无望的公众混淆的主题中提出的一个非常清晰的问题，这个问题由神秘的规范和令人惊讶的细微之处推动！）
...... http://example.com/../foo怎么样？这是一个有效的绝对URI吗？
没有。它是无效的绝对URI，因为它试图引用命名权限的命名空间（root）之外的地方。
（相应地，我已经获得了应有的＆＃34; 400 Bad request＆＃34;服务器在尝试提供类似的东西时的响应。）
< / LI>但是，假设您真的打算询问有效，但同样非标准化的绝对路径，例如/root/../foo：@ rdlowrey＆＃39;答案是正确的：如果可以的话，更好地将它们标准化。
（再一次，作为一个例子，我的代理在浏览器发送到同一服务器时工作正常的页面上失败了，这会使点部分正常化，而不是依靠服务器做同样的事情。）
但是，我无法找到RFC的确切规范 符合要求的URI可以包含＆＃34; ..＆＃34;细分 - 他们是否被允许进入 绝对路径/ URI，服务器是否必须规范化此类URI？ 或者这取决于客户？