Hi Lance,
On 2/10/23 7:10 PM, Lance Dockins wrote:
Thanks, Dmitry.
Is it correct to assume that this setting just forces all POST bodies
into a file (like shutting off client body buffers)? And would that be
true even with the “clean” directive?
>
> The “clean” value sounds like it just retains the POST body file until
> the request completes (at which point it’s cleaned), but if that’s an
> incorrect understanding, please let me know.
yes, "client_body_in_file_only clean" ensures two things:
1) the request body is always in a file
2) the temporary file is unlinked from a directory at the moment the
request finishes.
By default, client_body_in_file_only is off which means
that the file is unlinked from directory right away at the moment
the file is created (thus making the file inaccessible by a name, only
through open file descriptor).
I was sort of hoping to use memory buffers for smaller request body
sizes and only use file for larger request bodies. But if this setting
is the only solution to the problem (or if one of the settings is going
to do what I’m describing), I’ll go with that.
The another option is to increase the client_body_buffer_size ensuring the
the body is always in memory.
--
Lance Dockins
On Feb 10, 2023 at 8:49 PM -0600, Dmitry Volyntsev <xei...@nginx.com>,
wrote:
Hi Lance,
On 10.02.2023 18:24, Lance Dockins wrote:
This sort of NJS behavior "seems" like some sort of race condition
where NJS is trying to access the file after Nginx has already
disposed of it. Since this is a js_content directive, it should be
blocking and it seems to be one of the few stages where access to the
POST body is even possible. So it's unclear why the client body
buffer file wouldn't exist at the time that this code runs.
Take a look at
http://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_in_file_only.
_______________________________________________
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx
