HTTP请求URI是否允许包含“ ..”段？
根据RFC 2616第5.1.2节，它们可以引用绝对URI或绝对路径（该部分中的其他选项与此问题无关）。
绝对URI和绝对路径的含义在RFC 3986中描述，该文件还描述了一种标准化路径的算法（包括删除单点和双点元素）。
但是，我找不到确切的规范，即符合RFC的请求URI是否可以包含“ ..”段-绝对路径/ URI中是否允许使用这些段，并且服务器是否必须对此类URI进行标准化？还是取决于客户？
“ Location：”响应头有什么区别？根据规范，它们只能包含绝对URI，但是其中包括“ ..”部分吗？客户端在请求引用的资源之前也必须将其标准化吗？
需要澄清的是，我知道URI ../foo在这种情况下是非法的，那又如何http://example.com/../foo呢？那是有效的绝对URI吗？
我目前正在将客户端重定向到此类URI，并想知道这是否符合规范。
如果要“知道是否符合规范”，为什么不简单地参考相关规范？
RFC 3986第5.2节非常清楚应如何解析URI点段：
本节描述了一种算法，该算法用于将可能与给定基本URI相关的URI引用转换为引用目标的已解析组件。然后，可以按照第5.3节中的说明重组组件，以形成目标URI。该算法提供了确定的结果，可用于测试其他实现的输出。应用程序可以使用其他算法来实现相对参考分辨率，条件是结果与该算法给出的结果匹配。
例如，如果您跟随Location:标头，则通常明智的做法是规范化并解析无效的相对路径（Location:标头应该是绝对URI）。在这些情况下，您应该绝对遵循RFC 3986的说明来针对您的基本URI解析这些路径。
您是否应该在各地遍历URI中的点段？如果您能提供帮助，可能就没有办法，因为您依靠其他人正确地实施了规范。但是，传递带有点段的URI是否违反URI规范？没有。
从语法上来说，http://example.com/../foo是一个有效的 URI。
服务器如何解释该 URI 是另一回事。出于明显的安全原因，服务器必须非常小心地将 URI 转换为文件路径。通常，服务器会删除..段，或进行某种后处理以确保文件路径位于文档根目录内。