什么时候应该在HTTP URL中编码星号？

Question

根据RFC1738,可以在URL中使用未编码的星号(*)":

因此,只有字母数字,特殊字符"$ -_.+!*'(),"和用于其保留目的的保留字符可以在URL中未编码使用.

然而,w3.org的命名和寻址材料表明,星号"保留用于在特定方案中具有特殊的重要性",并暗示它应该被编码.

此外,根据RFC3986,URL是一个URI:

术语"统一资源定位符"(URL)指的是URI的子集,其除了标识资源之外,还通过描述其主要访问机制(例如,其网络"位置")来提供定位资源的手段.

它还指定星号是"sub-delim",它是"保留集"的一部分,并且:

URI生成应用程序应对与保留集中的字符对应的数据八位字节进行百分比编码,除非URI方案明确允许这些字符表示该组件中的数据.

它还明确指定它更新RFC1738.

我将所有这些都理解为要求将星号编码在URL中,除非它们用于URI方案定义的特殊用途.

是RFC1738的HTTP URI方案标准基准？它是否以某种方式免除星号编码,或者由于RFC3986而在这方面是否过时？

维基百科说,"当没有保留目的时,他不需要对字符进行百分比编码." RFC1738是否删除了星号的保留用途？

各种资源和工具似乎在这个问题上分开了.

PHP urlencode和rawurlencode- 后者声称遵循RFC3986 - 对星号进行编码.

然而,JavaScript的escape和encodeURIComponent 不编码的星号.

并且Java URLEncoder 不对星号进行编码:

特殊字符"."," - ","*"和"_"保持不变.

流行的在线 工具(谷歌搜索"在线网址编码器"的前两个结果)也不编码星号.该URL编码和解码工具明确指出,"[T]他保留的字符只有在特定情况下进行编码." 它继续列出星号和&符作为保留字符.它编码&符号,但不编码星号.

Stack Exchange社区中的其他类似问题似乎有陈旧,不完整或难以令人信服的答案:

• urlencode()'星号'(星号？)字符这个问题强调了Java和PHP处理星号之间的区别,并询问哪些是"正确的".该接受的答案只引用RFC1738,不提更近的RFC3986和解决冲突.另一个答案承认存在差异,并建议星号与特定URL不同,而不是其他URI,但它没有为该结论提供特定权限.
• URL可以带星号吗？ 一个答案仅引用较旧的RFC1738,并且接受的答案意味着当用作分隔符时它是可接受的,人们认为这是"保留目的".
• 我可以在网址中使用星号吗？该接受的答案似乎阻碍使用星号的没有澄清关于使用规则.另一个答案说你可以使用星号"因为它是一个保留字符".但是,如果你将它用于保留的目的,那是不是真的呢？
• 在网址中转义特殊字符 一个答案指出"对于是否必须在URL中编码星号存在一些歧义".我试图通过这个问题解决这种模棱两可的问题.
• Spring UriUtils和RFC3986这个问题指出UriUtil encodeQueryParam 声称遵循RFC3986,但它不编码星号.截至2014-08-01 12:50 PM CDT,该问题没有答案.
• 如何在JavaScript中编码URL？这似乎是Stack Overflow上规范的JavaScript URL编码问题,虽然答案注意到星号被排除在各种方法之外,但它们并没有解决它们是否应该存在的问题.

考虑到所有这些,何时应该在HTTP URL中编码星号？

Answer 1

简短的回答

URL语法的当前定义表明您永远不需要对URL的路径,查询或片段组件中的星号字符进行百分比编码.

HTTP 1.1

正如@Riley Major所指出的那样,HTTP 1.1引用的URL语法的RFC已经被RFC3986淘汰了,而这与使用星号一样,并不像最初引用的RFC那样黑白.

RFC2396(2005年1月之前的URL规范 - 原始答案)

星号永远不需要在HTTP 1.1 URL中编码,因为*在RFC2396中列为"无保留字符",用于在HTTP 1.1中定义URI语法.URL的路径组件中允许使用未保留的字符.

2.3.未保留的角色

URI中允许但没有保留目的的数据字符称为未保留.这些包括大写和小写字母,十进制数字以及一组有限的标点符号和符号.

   unreserved  = alphanum | mark

   mark        = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"

可以在不更改URI的语义的情况下转义未保留的字符,但除非在不允许未转义字符出现的上下文中使用URI,否则不应执行此操作.

RFC3986(HTTP的当前URL语法)

RFC3986修改RFC2396以使星号成为保留字符,因为它"通常不安全解码".我对此RFC的理解是,URL的路径,查询和片段组件中允许使用未编码的星号字符,因为这些组件未将星号指定为分隔符(2.2.保留字符):

这些字符称为"保留",因为它们可能(或可能不)通过通用语法定义为分隔符 ...如果URI组件的数据与保留字符作为分隔符的目的冲突,则冲突数据必须为百分比在URI形成之前编码.

此外,3.3 Path确认保留字符(sub-delims)的子集可以在路径段中被解码(路径组件的一部分被分解/):

除了分层路径中的点段("."和"..")之外,通用语法将路径段视为不透明.URI生成应用程序通常使用段中允许的保留字符....例如,分号(";")和等号("=")保留字符通常用于分隔适用于该段的参数和参数值.逗号(",")保留字符通常用于类似目的.例如,一个URI生成器可能使用诸如"name; v = 1.1"之类的段来表示对"name"的版本1.1的引用,而另一个URI生成器可能使用诸如"name,1.1"之类的段来表示相同.

HTTP 1.0

HTTP 1.0引用RFC1738来定义URL语法,通过一系列更新和废弃,它意味着它使用与HTTP 1.1相同的RFC作为URL语法.

就向后兼容性而言,RFC1738将星号指定为保留字符,但由于HTTP 1.0实际上没有为URL的路径组件中的未编码星号定义任何特殊含义,因此如果使用一个星号,它不会破坏任何内容.这应该意味着您仍然可以安全地将星号放在指向最旧系统的URL中.

作为旁注,星号字符在两个HTTP规范中的Request-URI中都有特殊含义,但不能用HTTP URL表示它:

星号"*"表示请求不适用于特定资源,而是适用于服务器本身,并且仅在使用的方法不一定适用于资源时才允许.一个例子是

   OPTIONS * HTTP/1.1

免责声明:我自己只是在阅读和解释这些RFC,所以我可能错了.