NJS Body File Access Race Condition?

[Dmitry Volyntsev]

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 <xeioex at 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.
>>
>>
>>
>>