nginx源码分析之http解码实现

分析nginx是如何解析并且存储http请求的。对非法甚至恶意请求的识别能力和处理方式。可以发现nginx采用状态机来解析http协议，有一定容错能力，但并不全面

相关配置

跟解码有关的配置

请求体有关配置

数据结构

解码的所有结果都保存在request结构里

1. ngx_http_request_t {  
2. ngx_but_t  *header_in;   //  buf，保存请求  
3. Ngx_http_headers_in_t headers_in;   //链表，保存请求中的请求头  
4. Ngx_http_headers_out_t headers_out;  //链表，保存response中的响应头  
5. 。。。  
6. }

保存请求头的结构

//Ngx_http_headers_in_t 结构

1. typedef struct {  
2.     ngx_list_t                        headers;  
3.     ngx_table_elt_t                  *host;  
4.     ngx_table_elt_t                  *connection;  
5. 。。。      
6.     ngx_str_t                         user;  
7.     ngx_str_t                         passwd;  
8. 。。。  
9.     ngx_array_t                       cookies;  
10.   
11.     ngx_str_t                         server;  
12.     off_t                             content_length_n;  
13.     time_t                            keep_alive_n;  
14.   
15.     unsigned                          connection_type:2;  
16.     unsigned                          chunked:1;  
17.     unsigned                          msie:1;  
18.     unsigned                          msie6:1;  
19.     unsigned                          opera:1;  
20.     unsigned                          gecko:1;  
21.     unsigned                          chrome:1;  
22.     unsigned                          safari:1;  
23.     unsigned                          konqueror:1;  
24. } ngx_http_headers_in_t;

解码流程

ngx_http_process_request_line(ngx_event_t *rev) //请求行 解码总入口

ngx_http_process_request_headers(ngx_event_t *rev) //请求头解码入口

所有请求头的handler在ngx_http_request.c:ngx_http_headers_in中 
例如：
Host头的handler是 ngx_http_process_host
ngx_http_process_host功能是，验证host有效性，查找virtual server，找到对应的server配置。

请求初始化

ngx_http_request_t *
ngx_http_create_request(ngx_connection_t *c)

r->header_in = hc->nbusy ? hc->busy[0] : c->buffer;
r->http_state = NGX_HTTP_READING_REQUEST_STATE;

解码请求行

1. ngx_http_process_request_line(ngx_event_t *rev)  
2. {  
3. 　　ngx_http_read_request_header(r);  //从连接中读取内容，放到header_in buf中,返回读取字节数，或错误码  
4. 　　  
5. 　　  
6. 　　ngx_http_parse_request_line(r, r->header_in);  
7. 　　// 状态机解析请求行,将method  schema host port uri  protocol version 分离出来  
8. 　　}

　　解析状态机图如下：

CR=’\r’

LF=’\n’

请求行 对应的正则

ngx_http_process_request_uri    //解析uri的函数，对自特殊字符进行了一些处理

定义：

Complex_uri: uri with “/.#” 
Quoted_uri: uri with “%”
Plus_in_uri: uri with “+”
Space_in_uri: uri with “ ”

Uri_ext： 最后一截uri， 非紧邻/的.后面的部分

逻辑

1. if (r->uri_ext) {  
2.         if (r->args_start) {  
3.             r->exten.len = r->args_start - 1 - r->uri_ext;  
4.         } else {  
5.             r->exten.len = r->uri_end - r->uri_ext;  
6.         }  
7.         r->exten.data = r->uri_ext;  
8. }

如果含有/.#%, 那么会给uri重新分配内存，并解析uri

1. if (r->complex_uri || r->quoted_uri) {  
2. r->uri.data = ngx_pnalloc(r->pool, r->uri.len + 1);    
3. ngx_http_parse_complex_uri(r, cscf->merge_slashes)  
4. }

uri解析的状态机图

请求行URI特殊字符处理

Nginx不支持第3部分， 不支持@

这里指的是6 7 8部分

HTTP0.9的支持

支持http 0.9

如果是协议版本小于1, 那么不会读取请求头

支持的方法

方法 
GET 

PUT 

POST 

COPY 
MOVE 
LOCK 
HEAD 
MKCOL 

PATCH

TRACE   NGX_HTTP_NOT_ALLOWED error code 405
DELETE 
UNLOCK 
OPTIONS
PROPFIND 

PROPPATCH

注意：这里说的支持，是说nginx解码时，能够识别这些方法。但是在后续的处理过程中不一定支持。例如，nginx遇到TRACE方法，会返回405 not allowed

未知的方法： 如果METHOD字符集符合 [A-B_]+, 会将请求放过去，交给后续处理
如果不符合[A-B_]+, 会报错误 400 bad request

解码请求头

ngx_http_process_request_headers(ngx_event_t *rev)

ngx_http_read_request_header // 从网络连接中读取内容
ngx_http_parse_header_line(r, r->header_in, cscf->underscores_in_headers);

请求头 对应的正则
Name    [0-9a-zA-Z-]? 最大长度32， 非法字符被忽略，超过32个的从头覆盖
_是否非法，看allow_underscores配置

value    [^ CRLF\0]+ 没有长度限制，以CRLF结尾

请求头解析的状态机图

非法头部处理

Header name中包含非法字符，则认为是非法头部，nginx默认抛弃这一行，另外也可由配置ignore_invalid_headers 确定

相同头部处理

策略一，第二个以上相同头部忽略 ngx_http_process_header_line
策略二，如果重复，返回400错误 ngx_http_process_unique_header_line
策略三，允许多头存在，用数组保存 ngx_http_process_multi_header_lines eg. X-Forwarded-For Cookie

策略四， 使用最靠后的头

冲突或关联头部处理

transfer_encoding content-length
在ngx_http_process_request_header中，当transfer-encoding value 为chunked content-length会失效。Transfer-encoding值只能为identity或chunked，否则报错


Connection keep-alive
如果connection 为keep-alive，那么keep-alive的值会生效
如果请求头connection没有指明为close， 且http版本大于1, 那么connection默认为keep-alive.

不支持多行请求头

由于 HTTP/1.1 协议里的规定,所以实际上 HTTP 协议支持多行请求头,它规定任何一个以空格开头的行,都是接续在前一行之后的内容。例如:
X-Random-Comment: 这是个长句子,
所以我们得换行处理一下,看着更整齐。

Nginx不支持多行请求头

Cookies处理
Nginx没有继续解析cookies值
https://github.com/cloudflare/lua-resty-cookie

解码请求体

nginx核心本身不会主动读取请求体，这个工作是交给请求处理阶段的模块来做，但是nginx核心提供了ngx_http_read_client_request_body()接口来读取请求体，另外还提供了一个丢弃请求体的接口-ngx_http_discard_request_body()，在请求执行的各个阶段中，任何一个阶段的模块如果对请求体感兴趣或者希望丢掉客户端发过来的请求体，可以分别调用这两个接口来完成。这两个接口是nginx核心提供的处理请求体的标准接口，如果希望配置文件中一些请求体相关的指令（比如client_body_in_file_only，client_body_buffer_size等）能够预期工作，以及能够正常使用nginx内置的一些和请求体相关的变量（比如$request_body和$request_body_file），一般来说所有模块都必须调用这些接口来完成相应操作，如果需要自定义接口来处理请求体，也应尽量兼容nginx默认的行为。

请求体的读取一般发生在nginx的content handler中，一些nginx内置的模块，比如proxy模块，fastcgi模块，uwsgi模块等，这些模块的行为必须将客户端过来的请求体（如果有的话）以相应协议完整的转发到后端服务进程，所有的这些模块都是调用了ngx_http_read_client_request_body()接口来完成请求体读取。值得注意的是这些模块会把客户端的请求体完整的读取后才开始往后端转发数据。

ngx_http_discard_request_body

使用接口

可用变量

以下仅为举例，不全

$http_xxxx 类型的变量， xxxx为header name 连接符变成下划线，大写字母变成小写字母

X-Real-IP 变量为 $http_x_real_ip

类似的有

$args_XXXX

$cookie_XXXX

$uri

$request_body
这个变量包含请求体。这个变量出现在proxy或fastcgi_pass所在的location
$request_body_file
Client请求体临时文件