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

相关配置

跟解码有关的配置

请求体有关配置

数据结构

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

ngx_http_request_t {
ngx_but_t  *header_in;   //  buf，保存请求
Ngx_http_headers_in_t headers_in;   //链表，保存请求中的请求头
Ngx_http_headers_out_t headers_out;  //链表，保存response中的响应头
。。。
}

保存请求头的结构

//Ngx_http_headers_in_t 结构

typedef struct {
    ngx_list_t                        headers;
    ngx_table_elt_t                  *host;
    ngx_table_elt_t                  *connection;
。。。    
    ngx_str_t                         user;
    ngx_str_t                         passwd;
。。。
    ngx_array_t                       cookies;

    ngx_str_t                         server;
    off_t                             content_length_n;
    time_t                            keep_alive_n;

    unsigned                          connection_type:2;
    unsigned                          chunked:1;
    unsigned                          msie:1;
    unsigned                          msie6:1;
    unsigned                          opera:1;
    unsigned                          gecko:1;
    unsigned                          chrome:1;
    unsigned                          safari:1;
    unsigned                          konqueror:1;
} ngx_http_headers_in_t;

解码流程

请求初始化

解码请求行

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

请求行 对应的正则

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

定义：

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

逻辑

if (r->uri_ext) {
        if (r->args_start) {
            r->exten.len = r->args_start - 1 - r->uri_ext;
        } else {
            r->exten.len = r->uri_end - r->uri_ext;
        }
        r->exten.data = r->uri_ext;
}

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

uri解析的状态机图

请求行URI特殊字符处理

这里指的是6 7 8部分

HTTP0.9的支持

支持的方法

PUT

POST

PATCH

PROPPATCH

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

解码请求头

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

请求头解析的状态机图

非法头部处理

相同头部处理

策略四， 使用最靠后的头

冲突或关联头部处理

不支持多行请求头

解码请求体

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默认的行为。

使用接口

可用变量

以下仅为举例，不全

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

X-Real-IP 变量为 $http_x_real_ip

类似的有

$args_XXXX

$cookie_XXXX

$uri

原文：http://blog.csdn.net/liujiyong7/article/details/44833475