<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection">
<div dir="auto">Thanks, Dmitry.<br />
<br />
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?<br />
<br />
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.<br />
<br />
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.</div>
</div>
<div name="messageSignatureSection"><br />
<div class="matchFont"><br />
--<br />
Lance Dockins<br />
<br /></div>
</div>
<div name="messageReplySection">On Feb 10, 2023 at 8:49 PM -0600, Dmitry Volyntsev <xeioex@nginx.com>, wrote:<br />
<blockquote type="cite" style="border-left-color: grey; border-left-width: thin; border-left-style: solid; margin: 5px 5px;padding-left: 10px;">Hi Lance,<br />
<br />
On 10.02.2023 18:24, Lance Dockins wrote:<br />
<blockquote type="cite">This sort of NJS behavior "seems" like some sort of race condition<br />
where NJS is trying to access the file after Nginx has already<br />
disposed of it. Since this is a js_content directive, it should be<br />
blocking and it seems to be one of the few stages where access to the<br />
POST body is even possible. So it's unclear why the client body<br />
buffer file wouldn't exist at the time that this code runs.<br />
<br /></blockquote>
<br />
Take a look at<br />
http://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_in_file_only.<br />
<br />
<br />
<br />
<br /></blockquote>
</div>
</body>
</html>