http - 斜杠 ("/") 等同于 HTTP URL 路径部分中的编码斜杠 ("%2F")

Question

我有一个站点以不同方式处理 URL 路径部分(不是查询字符串)中的 / 和 %2F。根据 RFC 或现实世界，这是一件坏事吗？

我问是因为我一直在使用我正在使用的 Web 框架(Ruby on Rails)以及它下面的层(Passenger、Apache，例如，我必须启用 ALLOW_ENCODED_SLASHES 用于 Apache)。我现在倾向于完全摆脱编码斜杠，但我想知道我是否应该在我看到涉及编码斜杠的奇怪行为时提交错误报告。

至于为什么我首先有编码的斜杠，基本上我有这样的路线:

:controller/:foo/:bar

其中 :foo 类似于可以包含斜杠的路径。我认为最直接的做法是对 foo 进行 URL 转义，这样路由机制就会忽略斜线。现在我有疑问，很明显框架并不真正支持这一点，但根据 RFC，这样做是错误的吗？

这是我收集到的一些信息:

RFC 1738(网址):

Usually a URL has the same interpretation when an octet is represented by a character and when it encoded. However, this is not true for reserved characters: encoding a character reserved for a particular scheme may change the semantics of a URL.

RFC 2396(URI):

These characters are called "reserved", since their usage within the URI component is limited to their reserved purpose. If the data for a URI component would conflict with the reserved purpose, then the conflicting data must be escaped before forming the URI.

(这里的转义是指编码保留字符以外的意思吗？)

RFC 2616 (HTTP/1.1):

Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396 [42]) are equivalent to their "% HEX HEX" encoding.

还有this bug report对于 Rails，他们似乎期望编码的斜线有不同的行为:

Right, I'd expect different results because they're pointing at different resources.

It's looking for the literal file foo/bar in the root directory. The non escaped version is looking for the file bar within directory foo.

从 RFC 中可以清楚地看出，原始字符与编码字符对于非保留字符是等价的，但是对于保留字符来说情况如何呢？

Answer 1

根据您收集的数据，我倾向于说 URI 中编码的 / 意味着在应用程序或 CGI 级别再次被视为 /。

也就是说，例如，如果您将 Apache 与 mod_rewrite 一起使用，它不会匹配模式期望斜杠与 URI 的编码斜杠。然而，一旦适当的 module/cgi/... 被调用来处理请求，它就会进行解码，例如，检索一个包含斜杠的参数作为请求的第一个组件网址。

如果您的应用随后使用此数据来检索文件(其文件名包含斜线)，那可能是一件坏事。

总而言之，我发现在 / 或 %2F 中看到行为差异是完全正常的，因为它们的解释将在不同级别完成。