request body filter last_buf

Maxim Dounin mdounin at
Fri Jan 28 23:19:05 UTC 2022


On Thu, Jan 27, 2022 at 11:02:45AM -0800, Dk Jack wrote:

> Thank you. Last few questions to complete my understanding?
> Were the module body filter callbacks being invoked even when
> content_length_n <= 0 prior to 7913:185c86b830ef change?

With content_length_n < 0 (the only valid case is -1) filters were 
never called.  With content_length_n == 0, filters were called.

Prior to 7913:185c86b830ef, the proper way for filters to detect 
that the body was fully read and processed was rb->rest == 0, 
which is immediately true when content_length_n is 0, see 
ngx_http_request_body_save_filter() for relevant code.  In 
7913:185c86b830ef and following 7914:9cf043a5d9ca the code was 
changed to rely on the last_buf instead, to make it possible to 
buffer response parts in intermediate body filters.

> Is the nginx body handling a store-and-forward architecture where it waits
> for the entire body or does it forward pkts as and when it receives
> (especially when dealing with large bodies).

Body handling might be different depending on the settings and/or 
particular request handling details.  By default, nginx reads the 
whole response body into rb->bufs (possible written to a temporary 
file) and then forwards the whole body.  Additionally, there is 
non-buffered request body reading, which is activated with the 
r->request_body_no_buffering flag (usually with settings like 
"proxy_request_buffering off;").  In this mode nginx forwards 
request body data immediately as it is received from the client, 
without disk buffering.

> What is the behavior of last_buf if it's not store-and-forward.

The last_buf flag is set on the last buffer, when the whole 
request body is read from the client and no additional data will 
follow.  It doesn't depend on the request body reading mode being 

Maxim Dounin

More information about the nginx-devel mailing list