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模塊等，這些模塊的行為必須將客戶端過來的請求體（如果有的話）以相應協議完整的轉發到后端服務進程，所有的這些模塊都是調用了ngx_http_read_client_request_body()接口來完成請求體讀取。值得注意的是這些模塊會把客戶端的請求體完整的讀取后才開始往后端轉發數據。

由于內存的限制，ngx_http_read_client_request_body()接口讀取的請求體會部分或者全部寫入一個臨時文件中，根據請求體的大小以及相關的指令配置，請求體可能完整放置在一塊連續內存中，也可能分別放置在兩塊不同內存中，還可能全部存在一個臨時文件中，最后還可能一部分在內存，剩余部分在臨時文件中。下面先介紹一下和這些不同存儲行為相關的指令：

client_body_buffer_size：設置緩存請求體的buffer大小，默認為系統頁大小的2倍，當請求體的大小超過此大小時，nginx會把請求體寫入到臨時文件中?？梢愿鶕I務需求設置合適的大小，盡量避免磁盤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()接口的實現，它的定義如下：

ngx_int_t ngx_http_read_client_request_body(ngx_http_request_t *r,  ngx_http_client_body_handler_pt post_handler) 

該接口有2個參數，第1個為指向請求結構的指針，第2個為一個函數指針，當請求體讀完時，它會被調用。之前也說到根據nginx現有行為，模塊邏輯會在請求體讀完后執行，這個回調函數一般就是模塊的邏輯處理函數。ngx_http_read_client_request_body()函數首先將參數r對應的主請求的引用加1，這樣做的目的和該接口被調用的上下文有關，一般而言，模塊是在content handler中調用此接口，一個典型的調用如下：

static ngx_int_t ngx_http_proxy_handler(ngx_http_request_t *r) {  ...  rc = ngx_http_read_client_request_body(r, ngx_http_upstream_init);    if (rc >= NGX_HTTP_SPECIAL_RESPONSE) {  return rc;  }   return NGX_DONE; }

上面的代碼是在porxy模塊的content handler，ngx_http_proxy_handler()中調用了ngx_http_read_client_request_body()函數，其中ngx_http_upstream_init()被作為回調函數傳入進接口中，另外nginx中模塊的content handler調用的上下文如下：

ngx_int_t ngx_http_core_content_phase(ngx_http_request_t *r,  ngx_http_phase_handler_t *ph) {  ...  if (r->content_handler) {  r->write_event_handler = ngx_http_request_empty_handler;  ngx_http_finalize_request(r, r->content_handler(r));  return NGX_OK;  }  ... } 

上面的代碼中，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()檢查客戶端是否發送了Expect: 100-continue頭，是的話則給客戶端回復"HTTP/1.1 100 Continue"，根據http 1.1協議，客戶端可以發送一個Expect頭來向服務器表明期望發送請求體，服務器如果允許客戶端發送請求體，則會回復"HTTP/1.1 100 Continue"，客戶端收到時，才會開始發送請求體。

接著繼續為接收請求體做準備工作，分配一個ngx_http_request_body_t結構，并保存在r->request_body，這個結構用來保存請求體讀取過程用到的緩存引用，臨時文件引用，剩余請求體大小等信息，它的定義如下。

<span style="font-family:SimSun;font-size:18px;">typedef struct {  ngx_temp_file_t   *temp_file;  ngx_chain_t   *bufs;  ngx_buf_t   *buf;  off_t    rest;  ngx_chain_t   *to_write;  ngx_http_client_body_handler_pt post_handler; } ngx_http_request_body_t;</span> 

• temp_file: 指向儲存請求體的臨時文件的指針；
• bufs: 指向保存請求體的鏈表頭；
• buf: 指向當前用于保存請求體的內存緩存；
• rest: 當前剩余的請求體大?。?/li>
• post_handler：保存傳給ngx_http_read_client_request_body()函數的回調函數。

做好準備工作之后，函數開始檢查請求是否帶有content_length頭，如果沒有該頭或者客戶端發送了一個值為0的content_length頭，表明沒有請求體，這時直接調用回調函數并返回NGX_OK即可。當然如果client_body_in_file_only指令被設置為on，且content_length為0時，該函數在調用回調函數之前，會創建一個空的臨時文件。

進入到函數下半部分，表明客戶端請求確實表明了要發送請求體，該函數會先檢查是否在讀取請求頭時預讀了請求體，這里的檢查是通過判斷保存請求頭的緩存(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變量只在當請求體已經被讀取并且是全部保存在內存中，才能取得相應的數據。

2，丟棄請求體

一個模塊想要主動的丟棄客戶端發過的請求體，可以調用nginx核心提供的ngx_http_discard_request_body()接口，主動丟棄的原因可能有很多種，如模塊的業務邏輯壓根不需要請求體 ，客戶端發送了過大的請求體，另外為了兼容http1.1協議的pipeline請求，模塊有義務主動丟棄不需要的請求體。總之為了保持良好的客戶端兼容性，nginx必須主動丟棄無用的請求體。下面開始分析ngx_http_discard_request_body()函數：

ngx_int_t ngx_http_discard_request_body(ngx_http_request_t *r) {  ssize_t size;  ngx_event_t *rev;   if (r != r->main || r->discard_body) {  return NGX_OK;  }   if (ngx_http_test_expect(r) != NGX_OK) {  return NGX_HTTP_INTERNAL_SERVER_ERROR;  }   rev = r->connection->read;   ngx_log_debug0(NGX_LOG_DEBUG_HTTP, rev->log, 0, "http set discard body");   if (rev->timer_set) {  ngx_del_timer(rev);  }   if (r->headers_in.content_length_n <= 0 || r->request_body) {  return NGX_OK;  }   size = r->header_in->last - r->header_in->pos;   if (size) {  if (r->headers_in.content_length_n > size) {   r->header_in->pos += size;   r->headers_in.content_length_n -= size;   } else {   r->header_in->pos += (size_t) r->headers_in.content_length_n;   r->headers_in.content_length_n = 0;   return NGX_OK;  }  }   r->read_event_handler = ngx_http_discarded_request_body_handler;   if (ngx_handle_read_event(rev, 0) != NGX_OK) {  return NGX_HTTP_INTERNAL_SERVER_ERROR;  }   if (ngx_http_read_discarded_request_body(r) == NGX_OK) {  r->lingering_close = 0;   } else {  r->count++;  r->discard_body = 1;  }   return NGX_OK; } 

接下來，如果還有剩余的請求體未處理，該函數調用ngx_handle_read_event()在事件處理機制中掛載好讀事件，并把讀事件的處理函數設置為ngx_http_discarded_request_body_handler。做好這些準備之后，該函數最后調用ngx_http_read_discarded_request_body()接口讀取客戶端過來的請求體并丟棄。如果客戶端并沒有一次將請求體發過來，函數會返回，剩余的數據等到下一次讀事件過來時，交給ngx_http_discarded_request_body_handler()來處理，這時，請求的discard_body將被設置為1用來標識這種情況。另外請求的引用數(count)也被加1，這樣做的目的是客戶端可能在nginx處理完請求之后仍未完整發送待發送的請求體，增加引用是防止nginx核心在處理完請求后直接釋放了請求的相關資源。

ngx_http_read_discarded_request_body()函數非常簡單，它循環的從鏈接中讀取數據并丟棄，直到讀完接收緩沖區的所有數據，如果請求體已經被讀完了，該函數會設置讀事件的處理函數為ngx_http_block_reading，這個函數僅僅刪除水平觸發的讀事件，防止同一事件不斷被觸發。
再來看一下讀事件的處理函數ngx_http_discarded_request_body_handler，這個函數每次讀事件來時會被調用，先看一下它的源碼：

void ngx_http_discarded_request_body_handler(ngx_http_request_t *r) {  ...   c = r->connection;  rev = c->read;   if (rev->timedout) {  c->timedout = 1;  c->error = 1;  ngx_http_finalize_request(r, NGX_ERROR);  return;  }   if (r->lingering_time) {  timer = (ngx_msec_t) (r->lingering_time - ngx_time());   if (timer <= 0) {   r->discard_body = 0;   r->lingering_close = 0;   ngx_http_finalize_request(r, NGX_ERROR);   return;  }   } else {  timer = 0;  }   rc = ngx_http_read_discarded_request_body(r);   if (rc == NGX_OK) {  r->discard_body = 0;  r->lingering_close = 0;  ngx_http_finalize_request(r, NGX_DONE);  return;  }   /* rc == NGX_AGAIN */   if (ngx_handle_read_event(rev, 0) != NGX_OK) {  c->error = 1;  ngx_http_finalize_request(r, NGX_ERROR);  return;  }   if (timer) {   clcf = ngx_http_get_module_loc_conf(r, ngx_http_core_module);   timer *= 1000;   if (timer > clcf->lingering_timeout) {   timer = clcf->lingering_timeout;  }   ngx_add_timer(rev, timer);  } }