Nginx系列（十九）：URI转义机制（部分转载）

一、URI和特殊字符

源文档 https://www.cnblogs.com/upyun/p/8267334.html

1. URI

URI，全称是 Uniform Resource Identifiers，即统一资源标识符，用于在互联网上标识一个资源，比如 https://www.upyun.com/products/cdn 这个 URI，指向的是一张漂亮的，描述又拍云 CDN 产品特性的网页。

2. URI 的组成

完整的 URI，由四个主要的部分构成：

scheme 表示协议，比如 http，ftp 等等，详细介绍可以参考 rfc2396#section-3.1。
authority，用:// 来和 scheme 区分。从字面意思看就是“认证”，“鉴权”的意思，引用 rfc2396#secion-3.2 的一句话：

This authority component is typically defined by an Internet-based
server or a scheme-specific registry of naming authorities.

这个“认证”部分，由一个基于 Internet 的服务器定义或者由命名机关注册登记（和具体的协议有关）。
而常见的 authority 则是：“由基于 Internet 的服务器定义”，其格式如下：

userinfo 这个域用于填写一些用户相关的信息，比如可能会填写 “user:password”，当然这是不被建议的。抛开这个不讲，后面的“host:port”则是被熟知的服务器地址了，host 可以是域名，也可以是对应的 IP 地址，port 表示端口，这是一个可选项，如果不填写，会使用默认端口（也是和协议相关，比如 http 协议默认端口是 80）。
path，在 scheme 和 authority 确定下来的情况下标识资源，path 由几个段组成，每个段用 / 来分隔。注意，path 不等同于文件系统定义的路径。
query，查询串（或者说参数串），用 ? 和 path 区分开来，其具体的含义由这个具体资源来定义。

3. 保留字符

从上面的描述里看，URI 的这 4 个组件，由特定的分隔符来分离，这些分隔符各自有着特殊含义，而如果这些分隔符出现在某个组件内，比如 path 是 /a/b?c.html，那么从 URI 整体角度来看的话， c.html 会被当做是 query，这样就破坏了 path 原本的含义，因此 URI 引入了保留字符集，这些字符有着特殊的目的，如果它们被用于描述资源（而不是作为分隔符出现），那么必须对它们转义。
那么什么情况下需要对一个字符转义呢，引用 rfc2395#section-2.2 的一句话：
In general, a character is reserved if the semantics of the URI changes if the character is replaced with its escaped US-ASCII encoding.
即如果转义前后这个字符会影响到整个 URI 的意义，则它必须被转义。
由于 URI 由多个组件构成，一个字符不转义，可能会对其中一个组件会造成影响，但对另一个组件没有影响，所以“保留字符集”是由具体的 URI 组件来规定的。
• 对 path 部分而言，保留字符集是（参考自 rfc2396）：
reserved = “/” | “?” | “;” | “=”
• 对 query 部分而言，保留字符集是（参考自 rfc2396）：
reserved = “;” | “/” | “?” | “:” | “@” | “&” | “=” | “+” | “,” | “$”
字符的转义规则如下：
escaped = “%” hex hex
hex = digit | “A” | “B” | “C” | “D” | “E” | “F” |
“a” | “b” | “c” | “d” | “e” | “f”
比如 , 转义后为 %2C。

4. 特殊字符

有一类不被允许用在 URI 里的特殊字符，它们被称为控制字符，即 ASCII 范围在0-31 之间的字符，以及 ASCII 码为 127 的这个字符。比如 \t，\a 这些（不包括空格），因为这些字符不可打印而且在某些场景下可能会消失。
另外一类则是扩展 ASCII 码，即范围 128-255 的那些字符，它们不属于 “US-ASCII coded character set”，因此这些字符如果出现在 URI 中，需要被转义。

URLs are written only with the graphic printable characters of the
US-ASCII coded character set. The octets 80-FF hexadecimal are not
used in US-ASCII, and the octets 00-1F and 7F hexadecimal represent
control characters; these must be encoded.

5. 不安全字符

Characters can be unsafe for a number of reasons. The space character
is unsafe because significant spaces may disappear and insignificant
spaces may be introduced when URLs are transcribed or typeset or
subjected to the treatment of word-processing programs. The characters
“<” and “>” are unsafe because they are used as the delimiters around
URLs in free text; the quote mark (“””) is used to delimit URLs in
some systems. The character “#” is unsafe and should always be encoded
because it is used in World Wide Web and in other systems to delimit a
URL from a fragment/anchor identifier that might follow it. The
character “%” is unsafe because it is used for encodings of other
characters. Other characters are unsafe because gateways and other
transport agents are known to sometimes modify such characters. These
characters are “{“, “}”, “|”, “", “^”, “~”, “[”, “]”, and “`”.

这段话引用自 rfc1738 2.2 节。因为种种的原因，存在一类字符，它们是 “unsafe” 的，不加处理地存在在 URI 里，会破坏 URI 的语义完整性，对于这类字符，如果要出现在 URI 里，那么也得进行转义。

二、Nginx的URI转义机制

nginx （以现在最新的 1.13.8 版本为准）提供了一个名为 ngx_escape_uri 的函数，函数原型如下：

uintptr_t ngx_escape_uri(u_char *dst, u_char *src, size_t size,
         ngx_uint_t type);

第三个参数，type，可以接受这些值：

#define NGX_ESCAPE_URI            0
#define NGX_ESCAPE_ARGS           1
#define NGX_ESCAPE_URI_COMPONENT  2
#define NGX_ESCAPE_HTML           3
#define NGX_ESCAPE_REFRESH        4
#define NGX_ESCAPE_MEMCACHED      5
#define NGX_ESCAPE_MAIL_AUTH      6

我们只关心其中的 NGX_ESCAPE_URI ，NGX_ESCAPE_ARGS ，NGX_ESCAPE_URI_COMPONENT ，根据 nginx 官方所提供的 nginx 模块和核心 API 介绍，这三个宏的含义如下：

Type Definition
NGX_ESCAPE_URI: Escape a standard URI
NGX_ESCAPE_ARGS: Escape query arguments
NGX_ESCAPE_URI_COMPONENT: Escape the URI after the domain

对应地，ngx_escape_uri这个函数，内置了几个相关的 bitmap，区别就是在于各自的转义字符集，具体可以查阅 nginx 的源码（src/core/ngx_string.c）。其中：

• 针对整个 URI 的转义处理，ngx_escape_uri 会把 " ", “#”, “%”, “?” 以及 %00-%1F 和 %7F-%FF 的字符转义；
• 针对 query 的转义，会把 " ", “#”, “%”, “&”, “+”, “?” 以及 %00-%1F 和 %7F-%FF 的字符转义；
• 针对 path + query（称之为 the URI after the domain）的转义，会把除英文字母，数字，以及 “-”, “.”, “_”, “~” 这些以外的字符全部转义。

可以看到，NGX_ESCAPE_URI 和 NGX_ESCAPE_ARGS 没有处理不安全字符，前者站在处理整个的 URI 的角度上编码，后者站在处理 query 的角度上编码；而 NGX_ESCAPE_URI_COMPONENT，处理角度不是整个 URI，而是 domain 之后的 URI 组件，它兼顾 path 和 query 的保留字符集，更加严格，遵守了 rfc3986#section-2.2 的规范。
这里顺便提一下 ngx_proxy 模块对应的 URI 转义处理，在构造向上游发送的请求行时，ngx_proxy 模块针对 proxy_pass 指令做出了不同的处理：

• 如果指定的 URI 包含了变量，将解析变量，然后直接将解析后的 URI 发送到上游；

• 如果 URI 不含变量，且没有指定 path 部分，将使用客户端发来的 path 部分拼接到 URI 中，然后发送到上游；

• 如果URI 不含变量，且指定了 path，这里的处理比较特殊，nginx 会把解码过的，由客户端发来的 URI 里的 path 部分（去掉和当前 location 的公共前缀），进行编码（按 NGX_ESCAPE_URI 来操作），和 proxy_pass 指令指定 的 path 拼接，发送到上游，比如这样的配置：

    location /foo {
        proxy_pass http://127.0.0.1:8082/bar;
    }
  

如果客户端发来的 URI 里 path 是 /foo/%5B-%5D，最终上游的 URI path 会是 /bar/[-]。
因此我们在做 nginx conf 配置的时候，也需要小心考虑 URI 编码的问题。

三、Nginx编解码机制

1. 解码（ngx_http_process_request_uri -> ngx_http_parse_complex_uri）

对于未解码的uri，保存在r->unparsed_uri。而如果uri存在r->complex_uri或r->quoted_uri情况，则需要对unparsed_uri进行解码，并保存在r->uri中。

• r->complex_uri
  即uri存在“/.”、“//”、“#”的情况。为什么这几种情况需要解码处理？
  1）对于“/.”，可能存在“/./”或“/…/”的情况，此时需要对路径进行简化；
  2）对于“//”，需要根据配置简化为单斜杠；
  3）uri中的#用来指导浏览器动作，对服务器端完全无作用，所以http请求中不应包含#字符。
• r->quoted_uri
  即uri转义情况，需要对已转义的字符进行解码保存。
• r->valid_unparsed_uri
  当uri中存在空格时，不需要对其进行解码保存（可能空格可以hash？），但会置r->valid_unparsed_uri为1，即r->unparsed_uri保存的uri不有效，对于这种情况，发送时会对uri进行转义。

2. 编码（ngx_http_proxy_create_request -> ngx_escape_uri）

对于nginx的uri转义，可以这么理解：

• 如果指定了uri（包含变量），那么直接使用指定的uri；
• 如果不指定uri，直接使用客户端的未解码的uri（r->unparsed_uri）。除非这个未解码的uri不符合nginx要求（r->valid_unparsed_uri = 0），即uri包含空格，那么需要nginx重新编码。
• 如果指定了uri（不含变量），那么使用指定uri+客户uri，这相当于nginx自己生成的uri，所以需要根据nginx的要求进行uri编码。

四、总结

在做相关的代理服务，网关服务时，URI 的编解码处理都是非常重要的，某些场景我们可能需要用 URI 来做 key（比如作为 hash 函数的因子），如果不处理好编解码问题，可能在 URI 复杂的情况下会达不到我们的预期效果，反而会浪费很多时间去排查问题的原因，特别地，在使用 nginx 和 ngx_lua 做服务时，我们更应该熟知它们在 URI 编解码上的区别，在理解它们的区别上做自身的业务处理，避免踩坑。