If it matters, I’m using Nginx 1.23.3 and NJS 0.7.10
--
Lance Dockins
On Feb 10, 2023 at 8:24 PM -0600, Lance Dockins <la...@wordkeeper.com>, wrote:
> NJS seems to be throwing an error when trying to access the temp body file
> created for POST bodies that are larger than the client body buffer size.
>
> I've verified that Nginx and NJS have access to this folder location. As a
> test, I placed a permanent file in the body temp folder location and can read
> from that file without an issue in NJS code. But if I grab the full path to
> the temp body file from Nginx and then try to read that file's contents, NJS
> throws an error indicating that the file doesn't exist.
>
> Here's a code sample:
> let body = '';
> if(!r.variables.request_body_file){
> > quote_type
> > body = r.requestText;
> }
> else{
> > quote_type
> > log.write(logpath, r.variables.request_body_file, r);
> > let fs = require('fs');
> > body = fs.readFileSync(r.variables.request_body_file);
> }
>
> The log.write call is a utility function that just allows me to log the
> contents of the variable in the sample. In this code,
> r.variables.request_body_file logs a full file path to the temp file for the
> POST body. Something like this:
> /var/lib/nginx/body/0000000128
>
> But trying to access and read that file immediately following that yields an
> error:
> 2023/02/10 20:14:05 [error] 609307#609307: *1555 js exception: Error: No such
> file or directory
> at fs.readFileSync (native)
>
> Again, it's not a permissions issue as a permanent test file exists in the
> same folder and is readable in the same code block without an issue.
>
> This code is currently inside of a js_content filter. Since js_content runs
> very late in the process, the temp file seems like it "should" still be in
> place. After all, reading r.requestText works just fine. The only time the
> problem surfaces is when the client body exceeds the buffer size (even if the
> buffer size is high) as that's where file access has to occur. Since the
> POST bodies can sometimes be very large in this particular route, it's not
> really a viable option to try to match the client body buffer size to the
> client body max size. So being able to access and read the POST body temp
> file is important since there are bound to be situations where a request
> crosses beyond the buffer size regardless of how high it goes (not that
> higher is necessarily always a good idea).
>
> 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.
>
> Is this a bug in NJS? Or is there some sort of alternative solution (e.g.
> settings adjustment in Nginx itself) that might resolve the problem?
>
> Thanks in advance for any insights.
>
>
> --
> Lance Dockins
>
_______________________________________________
nginx mailing list
nginx@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx
