request body filter last_buf
Maxim Dounin
mdounin at mdounin.ru
Fri Jan 28 23:19:05 UTC 2022
Hello!
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
used.
--
Maxim Dounin
http://mdounin.ru/
More information about the nginx-devel
mailing list