We’ve been experimenting with NJS in its current form (as compared with the more established LuaJIT integration provided by OpenResty) and it’s surfaced a series of questions about objects and features in NJS that the documentation, examples, recordings, and 3rd party examples don’t seem to answer very well.  I’m not sure if those should be asked here or in another division of Nginx but I wanted to lay them out.

Request Data

• Is there already an NJS object or are there plans for an object that parses and maps POST key/value pairs into a JSON object?
• Is there already an NJS object or are there plans for an object that parses out the cookies into key/value pairs of a JSON object?

We’re been experimenting with args, variables, rawVariables, etc and as a general rule, those objects seem to always come back as empty objects except for the args array which seems to always include the parsed output of the query string in a key/value pairing.  That might also be a fallacy of our testing methodology since we’re using JSON.stringify to visualize the output in the browser.  The documentation doesn’t fully flesh out what would be contained in these r and s values so it’s hard to really determine what they might or should contain without trying something like that.  Thus far, the only way we have found to retrieve cookies or POST vars from the request is by writing our own parsing logic in JS and passing the requestText to those to parse them out in various ways depending on whether they are url encoded, form/multipart, cookies, etc.

Note that we are testing this via the js_content tie in.

Variables

• What exactly should r.variables and r.rawVariables contain?  The assumption that I’ve been making is that those correspond to the variables defined in the Nginx configuration or Nginx variables that were set by NJS (making them editable by NJS as well but also available to Nginx conf).  Thus far we just get empty objects in response to that when outputting that via the method I named above.  But we most definitely have a TON of Nginx variables that we’ve manually set in the conf aside from the core Nginx variables

Access Filters

• Are there any plans to add an access phase filter?  I know that this can be simulated via the js_content tie in but that phase runs later than the access phase in Nginx anyway and requires you to either do a subrequest or internalRedirect over to a named backend route in order to both access filter the request AND also support the intended functionality of the location block where that is used.  That’s both more cumbersome and slower than it would be to just use the regular Nginx content phase and configuration for content and use NJS for access control in the access phase of the request.

Obviously LuaJIT and OpenResty are much more mature and there’s an argument to be had for LuaJIT being more performant but it’s not as well supported as NJS and JS is a much friendlier ecosystem to than LuaJIT so we prefer NJS/JS if possible.  None of that is even accounting for all of the more complex dependency management that you have to do with LuaJIT if you don’t just use a straight OpenResty build.  So ideally we’d prefer to use NJS if it is workable.  That said, at the moment, though, there appear to be a few key things in the basic use and scripting of the request that LuaJIT/OpenResty implementations have that NJS doesn’t even though they seem like they are really things that should be in any request scripting system like:

1. Filters for the different phase of the Nginx request
2. Direct variable access to the Nginx variables (either read only or writable depending on the context within which they were created)
3. Array like access to the request arguments (e.g. cookies, post args, query string args, etc).  Right now the only version of this that we’ve found reliably working in the js_content phase is query string related stuff (in the args array)

Apologies if there are holes in my understanding here or confusion here - even so much as if this is directed to the wrong “forum” within Nginx.  NJS looks awesome but the lack of clarity in the documentation and the tendency we’ve seen to get an empty object back out of JSON.stringify from what appears like it should be a fully filed out object has made it hard to get much headway into this.


--
Lance Dockins

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx