首先，读取请求体已进入HTTP要求11相，我们需要做的请求正文部分处理一些模块，所以这个模块需要注册功能在这个阶段，在阅读功能要求的身体ngx_http_read_client_request_body()是存在的。仅仅只是不同的模块可能对请求体做不同的处理。读取请全体的函数是在某个模块的conent_handler函数中包括的。比方比方proxy模块，fastcgi模块，uwsgi模块等这些模块对请求体感兴趣，那么读取请求体的函数在这些模块的content_handler中注冊。

上节说到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默认的行为。

1，读取请求体

请求体的读取一般发生在nginx的content handler中。一些nginx内置的模块。比方proxy模块，fastcgi模块。uwsgi模块等。这些模块的行为必须将client过来的请求体（假设有的话）以对应协议完整的转发到后端服务进程，全部的这些模块都是调用了ngx_http_read_client_request_body()接口来完毕请求体读取。

值得注意的是这些模块会把client的请求体完整的读取后才開始往后端转发数据。

因为内存的限制，ngx_http_read_client_request_body()接口读取的请求体会部分或者所有写入一个暂时文件里，依据请求体的大小以及相关的指令配置，请求体可能完整放置在一块连续内存中。也可能分别放置在两块不同内存中，还可能所有存在一个暂时文件里，最后还可能一部分在内存，剩余部分在暂时文件里。以下先介绍一下和这些不同存储行为相关的指令：

client_body_buffer_size：设置缓存请求体的buffer大小。默觉得系统页大小的2倍，当请求体的大小超过此大小时，nginx会把请求体写入到暂时文件里。能够依据业务需求设置合适的大小。尽量避免磁盘io操作；

client_body_in_single_buffer：指示是否将请求体完整的存储在一块连续的内存中，默觉得off，假设此指令被设置为on。则nginx会保证请求体在不大于client_body_buffer_size设置的值时，被存放在一块连续的内存中，但超过大小时会被整个写入一个暂时文件；

client_body_in_file_only：设置是否总是将请求体保存在暂时文件里，默觉得off，当此指定被设置为on时，即使客户端显示指示了请求体长度为0时。nginx还是会为请求创建一个暂时文件。

接着介绍ngx_http_read_client_request_body()接口的实现，它的定义例如以下：

该接口有2个參数，第1个为指向请求结构的指针。第2个为一个函数指针。当请求体读完时。它会被调用。之前也说到依据nginx现有行为，模块逻辑会在请求体读完后运行。这个回调函数一般就是模块的逻辑处理函数。ngx_http_read_client_request_body()函数首先将參数r相应的主请求的引用加1。这样做的目的和该接口被调用的上下文有关。一般而言。模块是在content handler中调用此接口，一个典型的调用例如以下：

上面的代码是在porxy模块的content handler，ngx_http_proxy_handler()中调用了ngx_http_read_client_request_body()函数，当中ngx_http_upstream_init()被作为回调函数传入进接口中。另外nginx中模块的content
handler调用的上下文例如以下：

上面的代码中，content handler调用之后，它的返回值作为參数调用了ngx_http_finalize_request()函数。在请求体没有被接收全然时，ngx_http_read_client_request_body()函数返回值为NGX_AGAIN。此时content
handler，比方ngx_http_proxy_handler()会返回NGX_DONE，而NGX_DONE作为參数传给ngx_http_finalize_request()函数会导致主请求的引用计数减1，所以正好抵消了ngx_http_read_client_request_body()函数开头对主请求计数的加1。

接下来回到ngx_http_read_client_request_body()函数。它会检查该请求的请求体是否已经被读取或者被丢弃了，假设是的话。则直接调用回调函数并返回NGX_OK，这里实际上是为子请求检查，子请求是nginx中的一个概念，nginx中能够在当前请求中发起另外一个或多个全新的子请求来訪问其它的location，关于子请求的具体介绍会在后面的章节作具体分析，一般而言子请求不须要自己去读取请求体。

函数接着调用ngx_http_test_expect()检查client是否发送了Expect: 100-continue头，是的话则给client回复"HTTP/1.1
100 Continue"。依据http 1.1协议，client能够发送一个Expect头来向server表明期望发送请求体，server假设同意client发送请求体。则会回复"HTTP/1.1 100 Continue"，client收到时。才会開始发送请求体。

接着继续为接收请求体做准备工作。分配一个ngx_http_request_body_t结构，并保存在r->request_body，这个结构用来保存请求体读取过程用到的缓存引用，暂时文件引用，剩余请求体大小等信息，它的定义例如以下。

temp_file: 指向储存请求体的暂时文件的指针；

bufs: 指向保存请求体的链表头；

buf: 指向当前用于保存请求体的内存缓存。

rest: 当前剩余的请求体大小；

post_handler：保存传给ngx_http_read_client_request_body()函数的回调函数。

做好准备工作之后，函数開始检查请求是否带有content_length头。假设没有该头或者客户端发送了一个值为0的content_length头，表明没有请求体，这时直接调用回调函数并返回NGX_OK就可以。当然假设client_body_in_file_only指令被设置为on，且content_length为0时。该函数在调用回调函数之前。会创建一个空的暂时文件。

进入到函数下半部分，表明client请求确实表明了要发送请求体，该函数会先检查是否在读取请求头时预读了请求体。这里的检查是通过推断保存请求头的缓存(r->header_in)中是否还有未处理的数据。假设有预读数据。则分配一个ngx_buf_t结构，并将r->header_in中的预读数据保存在当中，而且假设r->header_in中还有剩余空间，而且可以容下剩余未读取的请求体，这些空间将被继续使用。而不用分配新的缓存，当然甚至假设请求体已经被整个预读了，则不须要继续处理了，此时调用回调函数后返回。

假设没有预读数据或者预读不完整，该函数会分配一块新的内存（除非r->header_in还有足够的剩余空间）。另外假设request_body_in_single_buf指令被设置为no。则预读的数据会被拷贝进新开辟的内存块中，真正读取请求体的操作是在ngx_http_do_read_client_request_body()函数，该函数循环的读取请求体并保存在缓存中。假设缓存被写满了。当中的数据会被清空并写回到暂时文件里。当然这里有可能不能一次将数据读到。该函数会挂载读事件并设置读事件handler为ngx_http_read_client_request_body_handler。另外nginx核心对两次请求体的读事件之间也做了超时设置，client_body_timeout指令能够设置这个超时时间，默觉得60s，假设下次读事件超时了，nginx会返回408给客户端。

终于读完请求体后。ngx_http_do_read_client_request_body()会依据配置，将请求体调整到预期的位置(内存或者文件)。所有情况下从主体的请求能够r->request_body的bufs获取名单，列表可以是向上2节点，每个节点是一个buffer，但是，这buffer所述内容可以被存储在存储器。它可被存储在一个磁盘文件。

另$request_body变量只有当请求体已被读出并存储在存储器中用于所有，能力，以获得相应的数据。