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

Question

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

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

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

:controller/:foo/:bar

其中:foo就像一个可以包含斜杠的路径.我认为最简单的做法就是只进行URL转义,foo以便路由机制忽略斜杠.现在我有疑虑,而且很明显框架并不真正支持这一点,但根据RFC,这样做是错误的吗？

以下是我收集的一些信息:

RFC 1738(URL):

当八位字节由一个字符表示并且在编码时,URL通常具有相同的解释.但是,保留字符不是这样:编码为特定方案保留的字符可能会更改URL的语义.

RFC 2396(URI):

这些字符称为"保留",因为它们在URI组件中的使用仅限于其保留的用途.如果URI组件的数据与保留的目的冲突,则必须在形成URI之前转义冲突的数据.

(这里的转义是否意味着除了编码保留字符之外的东西？)

RFC 2616(HTTP/1.1):

除"保留"和"不安全"集合之外的字符(参见RFC 2396 [42])等同于它们的"%"HEX HEX"编码.

还有针对Rails的错误报告,他们似乎希望编码的斜杠行为不同:

是的,我期望得到不同的结果,因为他们指的是不同的资源.

它正在根目录中查找文字文件'foo/bar'.非转义版本正在查找目录foo中的文件栏.

从RFC中可以清楚地看出,原始与编码相当于未保留的字符,但保留字符的故事是什么？

Answer 1

根据您收集的数据,我倾向于说在uri中编码的"/"在application/cgi级别再次被视为"/".

也就是说,如果你正在使用apache mod_rewrite,它将不会匹配模式,期望对URI的斜杠与其中的编码斜杠.但是,一旦调用适当的module/cgi/...来处理请求,它就可以进行解码,例如,检索包含斜杠的参数作为URI的第一个组件.

如果您的应用程序然后使用此数据来检索文件(其文件名包含斜杠),那可能是一件坏事.

总而言之,我发现在"/"或"%2F"中看到行为的差异是完全正常的,因为他们的解释将在不同的层次上完成.

Answer 2

根据最初的W3C建议,%2Fvs 的故事/是,"必须暗示一个等级结构":

例2

URI

http://www.w3.org/albert/bertram/marie-claude

和

http://www.w3.org/albert/bertram%2Fmarie-claude

不相同,因为在第二种情况下,编码的斜杠没有分层重要性.

Answer 3

我还有一个网站,其中包含许多带有urlencoded字符的网址.我发现很多网络API(包括Google网站管理员工具和几个Drupal模块)都会在urlencoded字符上跳过.许多API会在其进程中的某个时刻自动解码URL,然后将结果用作URL或HTML.当我发现其中一个问题时,我通常会对该API的结果进行双重编码(将%2f变为%252f).但是,这将打破其他不期望双重编码的API,因此这不是一个通用的解决方案.

就个人而言,我尽可能多地删除网址中的特殊字符.

另外,我在我的网址中使用不依赖于urldecoding的ID号码:

example.com/blog/my-amazing-blog%2fstory/yesterday

变为:

example.com/blog/12354/my-amazing-blog%2fstory/yesterday

在这种情况下,我的代码只使用12354查找文章,其余的URL被我的系统忽略(但仍然用于搜索引擎优化.)此外,这个数字应该出现在未使用的URL组件之前.这样,即使%2f被错误地解码,网址仍然有效.

此外,请务必使用规范标记以确保网址错误不会转换为重复内容.