Setting to a nil value will unset the $Foo Nginx variable. Interface as well, by writing ngx.var, ngx.var, ngx.var, and etc. Nginx regex group capturing variables $1, $2, $3, and etc, can be read by this Many others are not, like $query_string, $arg_PARAMETER, and $http_NAME. Some special nginx variables like $args and $limit_rate can be assigned a value, That is, nginx variables cannot be created on-the-fly. Set $my_var '' # this line is required to create $my_var at config time Note that only already defined nginx variables can be written to. When setting nil or an empty Lua string value to ngx.arg, no data chunk will be passed to the downstream Nginx output filters at all.Ĭontext: set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, log_by_lua* The data chunk and "eof" flag passed to the downstream Nginx output filters can also be overridden by assigning values directly to the corresponding table elements.
Lua table insert index code#
When this table is used in the context of body_filter_by_lua*, the first element holds the input data chunk to the output filter code and the second element holds the boolean flag for the "eof" flag indicating the end of the whole output data stream. That writes out 88, the sum of 32 and 56. 'return tonumber(ngx.arg) + tonumber(ngx.arg)' When this is used in the context of the set_by_lua* directives, this table is read-only and holds the input arguments to the config directives: Delegating all network and disk I/O operations to Nginx's subrequests (via the method and similar) is strongly recommended for maximum performance.Ĭontext: set_by_lua*, body_filter_by_lua* Disk operations with relatively small amount of data can be done using the standard Lua io library but huge file reading and writing should be avoided wherever possible as they may block the Nginx process significantly. Network I/O operations in user code should only be done through the Nginx Lua API calls as the Nginx event loop may be blocked and performance drop off dramatically otherwise. The ability to require these packages was introduced in the v0.2.1rc19 release. It is also possible to directly require the packages in external Lua modules: Use of the eall flag is strongly discouraged due to its various bad side-effects. The packages can be introduced into external Lua modules like this: These packages are in the default global scope within ngx_lua and are always available within ngx_lua directives. The API is exposed to Lua in the form of two standard packages ngx and ndk. The Nginx Lua API described below can only be called within the user Lua code run in the context of these configuration directives. The various *_by_lua, *_by_lua_block and *_by_lua_file configuration directives serve as gateways to the Lua API within the nf file.
0 kommentar(er)
