不应在 URL 中使用星号的原因。
1 )根据标准,在未编码的 URL中允许使用星号,但根据RFC 1738 统一资源定位器 (URL) ,星号是特殊字符。所以在这种情况下它有一个特殊的用途。
RFC 1738 统一资源定位符 (URL) 1994 年 12 月
预订的:
许多 URL 方案为特殊含义保留某些字符:它们在 URL 的方案特定部分中的出现具有指定的语义。如果对应于八位字节的字符在方案中被保留,则必须对八位字节进行编码。字符“;”、“/”、“?”、“:”、“@”、“=”和“&”是可以在方案中为特殊含义保留的字符。方案中不得保留其他字符。
通常,当八位位组由字符表示时和对其进行编码时,URL 具有相同的解释。但是,对于保留字符则不是这样:对为特定方案保留的字符进行编码可能会改变 URL 的语义。
因此,只有字母数字、特殊字符“$-_.+!*'()”和用于其保留目的的保留字符可以在 URL 中未编码地使用。
另一方面,不需要编码的字符(包括字母数字)可以在 URL 的特定于方案的部分中编码,只要它们不被用于保留目的。
此外,在标头中,它根据RFC 2068 HTTP 1.1用于仅服务器声明。
9.2 选项
OPTIONS 方法表示请求有关在由 Request-URI 标识的请求/响应链上可用的通信选项的信息的请求。此方法允许客户端确定与资源相关联的选项和/或要求,或服务器的能力,而无需暗示资源操作或启动资源检索。
除非服务器的响应是错误的,否则响应不能包含除了可以被视为通信选项的实体信息(例如,Allow 是合适的,但 Content-Type 不是)。对此方法的响应不可缓存。
如果 Request-URI 是星号(“*”),则 OPTIONS 请求旨在应用于整个服务器。除了任何适用的通用或响应头字段外,200 响应应该包括指示服务器实现的可选功能(例如,Public)的任何头字段,包括本规范未定义的任何扩展。如 5.1.2 节所述,“OPTIONS *”请求可以通过代理应用,方法是在 Request-URI 中指定目标服务器,而不需要任何路径信息。
如果 Request-URI 不是星号,则 OPTIONS 请求仅适用于与该资源通信时可用的选项。除了任何适用的通用或响应头字段外,200 响应应该包括任何标头字段,这些标头字段指示服务器实现并适用于该资源(例如,允许)的可选功能,包括本规范未定义的任何扩展。如果 OPTIONS 请求通过代理,代理必须编辑响应以排除那些适用于代理能力并且已知通过该代理不可用的选项。
2 ) 这是RFC 3986 URI Generic Syntax January 2005的保留字符(子分隔符) (感谢@Daxim 指出这一点)。
2.2. 保留字符
URI 包括由“保留”集中的字符分隔的组件和子组件。这些字符被称为
“保留”,因为它们可能(或可能不)被
通用语法、每个特定于方案的语法或
URI 的解引用算法的特定于实现的语法定义为分隔符。
如果 URI 组件的数据与保留
字符作为分隔符的用途发生冲突,则必须在形成 URI 之前对冲突数据进行百分比编码。
保留= gen-delims / sub-delims
gen-delims = ":" / "/" / "?" /“#”/“[”/“]”/“@”
子分隔符=“!” /“$”/“&”/“'”/“(”/“)”/“*”/“+”/“”/“;” /“=”
保留字符的目的是提供一组可与 URI 中的其他数据区分开来的定界字符。在用相应的百分比编码八位字节替换保留字符方面不同的 URI 是不等价的。对保留字符进行百分比编码,或对与保留字符相对应的百分比编码八位字节进行解码,将改变大多数应用程序解释 URI 的方式。因此,保留集中的字符不受规范化的影响,因此可以安全地被特定于方案和特定于生产者的算法用于分隔 URI 中的数据子组件。
3 ) 在某些主机操作系统中,它被用作通配符。
无论哪种方式,您都应该避免在请求 URI 中使用未编码的星号。