Repository files navigation

ngx_http_lua_module - Embed the power of Lua into Nginx HTTP Servers.

This module is a core component ofOpenResty. If you are using this module,then you are essentially using OpenResty :)

This module is not distributed with the Nginx source. Seethe installation instructions.

• Name
• Status
• Version
• Videos
• Synopsis
• Description
• Typical Uses
• Nginx Compatibility
• Installation
  • Building as a dynamic module
  • C Macro Configurations
• Community
  • English Mailing List
  • Chinese Mailing List
• Code Repository
• Bugs and Patches
• LuaJIT bytecode support
• System Environment Variable Support
• HTTP 1.0 support
• Statically Linking Pure Lua Modules
• Data Sharing within an Nginx Worker
• Known Issues
  • TCP socket connect operation issues
  • Lua Coroutine Yielding/Resuming
  • Lua Variable Scope
  • Locations Configured by Subrequest Directives of Other Modules
  • Cosockets Not Available Everywhere
  • Special Escaping Sequences
  • Mixing with SSI Not Supported
  • SPDY Mode Not Fully Supported
  • Missing data on short circuited requests
• TODO
• Changes
• Build And Test
• Test Suite
• Copyright and License
• See Also
• Directives
• Nginx API for Lua
• Obsolete Sections
  • Special PCRE Sequences
  • Lua/LuaJIT bytecode support

Production ready.

This document describes ngx_luav0.10.28, which was releasedon 17 Jan, 2025.

• YouTube video "Hello World HTTP Example with OpenResty/Lua"

  

• YouTube video "Write Your Own Lua Modules in OpenResty/Nginx Applications"

  

• YouTube video "OpenResty's resty Command-Line Utility Demo"

  

• YouTube video "Measure Execution Time of Lua Code Correctly in OpenResty"

  

• YouTube video "Precompile Lua Modules into LuaJIT Bytecode to Speedup OpenResty Startup"

  

You are welcome to subscribe to ourofficial YouTube channel, OpenResty.

Back to TOC

 # set search paths for pure Lua external libraries (';;' is the default path): lua_package_path'/foo/bar/?.lua;/blah/?.lua;;'; # set search paths for Lua external libraries written in C (can also use ';;'): lua_package_cpath'/bar/baz/?.so;/blah/blah/?.so;;';server{location /lua_content{         # MIME type determined by default_type:default_type'text/plain';         content_by_lua_block{             ngx.say('Hello,world!')}}location /nginx_var{         # MIME type determined by default_type:default_type'text/plain';         # try access /nginx_var?a=hello,world         content_by_lua_block{             ngx.say(ngx.var.arg_a)}}location = /request_body{client_max_body_size50k;client_body_buffer_size50k;         content_by_lua_block{             ngx.req.read_body()  -- explicitly read the req body             local data = ngx.req.get_body_data()if data then                 ngx.say("body data:")                 ngx.print(data)return             end             -- body may get buffered in a temp file:             local file = ngx.req.get_body_file()if file then                 ngx.say("body is in file ", file)             else                 ngx.say("no body found")             end}}     # transparent non-blocking I/O in Lua via subrequests     # (well, a better way is to use cosockets)location = /lua{         # MIME type determined by default_type:default_type'text/plain';         content_by_lua_block{             local res = ngx.location.capture("/some_other_location")if res then                 ngx.say("status: ", res.status)                 ngx.say("body:")                 ngx.print(res.body)             end}}location = /foo{         rewrite_by_lua_block{             res = ngx.location.capture("/memc",{ args ={ cmd ="incr", key = ngx.var.uri}})}proxy_passhttp://blah.blah.com;}location = /mixed{         rewrite_by_lua_file /path/to/rewrite.lua;         access_by_lua_file /path/to/access.lua;         content_by_lua_file /path/to/content.lua;}     # use nginx var in code path     # CAUTION: contents in nginx var must be carefully filtered,     # otherwise there'll be great security risk!location~ ^/app/([-_a-zA-Z0-9/]+){set$path$1;         content_by_lua_file /path/to/lua/app/root/$path.lua;}location /{client_max_body_size100k;client_body_buffer_size100k;        access_by_lua_block{            -- check the client IP address is in our black listif ngx.var.remote_addr =="132.5.72.3" then                ngx.exit(ngx.HTTP_FORBIDDEN)            end            -- checkif the URI contains bad wordsif ngx.var.uri and                   string.match(ngx.var.request_body,"evil")            thenreturn ngx.redirect("/terms_of_use.html")            end            -- tests passed}        # proxy_pass/fastcgi_pass/etc settings}}

Back to TOC

This module embedsLuaJIT 2.0/2.1 into Nginx.It is a core component ofOpenResty. If you are usingthis module, then you are essentially using OpenResty.

Since versionv0.10.16 of this module, the standard Luainterpreter (also known as "PUC-Rio Lua") is not supported anymore. Thisdocument interchangeably uses the terms "Lua" and "LuaJIT" to refer to theLuaJIT interpreter.

By leveraging Nginx's subrequests, this module allows the integration of thepowerful Lua threads (known as Lua "coroutines") into the Nginx event model.

UnlikeApache's mod_luaandLighttpd's mod_magnet,Lua code executed using this module can be100% non-blocking on networktraffic as long as theNginx API for Lua provided bythis module is used to handle requests to upstream services such as MySQL,PostgreSQL, Memcached, Redis, or upstream HTTP web services.

At least the following Lua libraries and Nginx modules can be used with thismodule:

• lua-resty-memcached
• lua-resty-mysql
• lua-resty-redis
• lua-resty-dns
• lua-resty-upload
• lua-resty-websocket
• lua-resty-lock
• lua-resty-logger-socket
• lua-resty-lrucache
• lua-resty-string
• ngx_memc
• ngx_postgres
• ngx_redis2
• ngx_redis
• ngx_proxy
• ngx_fastcgi

Almost any Nginx modules can be used with this ngx_lua module by means ofngx.location.capture orngx.location.capture_multi but it isrecommended to use thoselua-resty-* libraries instead of creatingsubrequests to access the Nginx upstream modules because the former is usuallymuch more flexible and memory-efficient.

The Lua interpreter (also known as "Lua State" or "LuaJIT VM instance") isshared across all the requests in a single Nginx worker process to minimizememory use. Request contexts are segregated using lightweight Lua coroutines.

Loaded Lua modules persist in the Nginx worker process level resulting in asmall memory footprint in Lua even when under heavy loads.

This module is plugged into Nginx's "http" subsystem so it can only speakdownstream communication protocols in the HTTP family (HTTP 0.9/1.0/1.1/2.0,WebSockets, etc...). If you want to do generic TCP communications with thedownstream clients, then you should use thengx_stream_luamodule instead, which offers a compatible Lua API.

Back to TOC

Just to name a few:

• Mashup'ing and processing outputs of various Nginx upstream outputs (proxy, drizzle, postgres, redis, memcached, etc.) in Lua,
• doing arbitrarily complex access control and security checks in Lua before requests actually reach the upstream backends,
• manipulating response headers in an arbitrary way (by Lua)
• fetching backend information from external storage backends (like redis, memcached, mysql, postgresql) and use that information to choose which upstream backend to access on-the-fly,
• coding up arbitrarily complex web applications in a content handler using synchronous but still non-blocking access to the database backends and other storage,
• doing very complex URL dispatch in Lua at rewrite phase,
• using Lua to implement advanced caching mechanism for Nginx's subrequests and arbitrary locations.

The possibilities are unlimited as the module allows bringing together variouselements within Nginx as well as exposing the power of the Lua language to theuser. The module provides the full flexibility of scripting while offeringperformance levels comparable with native C language programs both in terms ofCPU time as well as memory footprint thanks to LuaJIT 2.x.

Other scripting language implementations typically struggle to match thisperformance level.

Back to TOC

The latest version of this module is compatible with the following versions of Nginx:

• 1.27.x (last tested: 1.27.1)
• 1.25.x (last tested: 1.25.1)
• 1.21.x (last tested: 1.21.4)
• 1.19.x (last tested: 1.19.3)
• 1.17.x (last tested: 1.17.8)
• 1.15.x (last tested: 1.15.8)
• 1.14.x
• 1.13.x (last tested: 1.13.6)
• 1.12.x
• 1.11.x (last tested: 1.11.2)
• 1.10.x
• 1.9.x (last tested: 1.9.15)
• 1.8.x
• 1.7.x (last tested: 1.7.10)
• 1.6.x

Nginx cores older than 1.6.0 (exclusive) arenot supported.

Back to TOC

It ishighly recommended to useOpenResty releaseswhich bundle Nginx, ngx_lua (this module), LuaJIT, as well as other powerfulcompanion Nginx modules and Lua libraries.

It is discouraged to build this module with Nginx yourself since it is trickyto set up exactly right.

Note that Nginx, LuaJIT, and OpenSSL official releases have various limitationsand long-standing bugs that can cause some of this module's features to bedisabled, not work properly, or run slower. Official OpenResty releases arerecommended because they bundleOpenResty's optimized LuaJIT 2.1 fork andNginx/OpenSSLpatches.

Alternatively, ngx_lua can be manually compiled into Nginx:

1. LuaJIT can be downloaded from thelatest release of OpenResty's LuaJIT fork. The official LuaJIT 2.x releases are also supported, although performance will be significantly lower for reasons elaborated above
2. Download the latest version of the ngx_devel_kit (NDK) moduleHERE
3. Download the latest version of ngx_luaHERE
4. Download the latest supported version of NginxHERE (SeeNginx Compatibility)
5. Download the latest version of the lua-resty-coreHERE
6. Download the latest version of the lua-resty-lrucacheHERE

Build the source with this module:

 wget'https://openresty.org/download/nginx-1.19.3.tar.gz' tar -xzvf nginx-1.19.3.tar.gzcd nginx-1.19.3/# tell nginx's build system where to find LuaJIT 2.0:export LUAJIT_LIB=/path/to/luajit/libexport LUAJIT_INC=/path/to/luajit/include/luajit-2.0# tell nginx's build system where to find LuaJIT 2.1:export LUAJIT_LIB=/path/to/luajit/libexport LUAJIT_INC=/path/to/luajit/include/luajit-2.1# Here we assume Nginx is to be installed under /opt/nginx/. ./configure --prefix=/opt/nginx \         --with-ld-opt="-Wl,-rpath,/path/to/luajit/lib" \         --add-module=/path/to/ngx_devel_kit \         --add-module=/path/to/lua-nginx-module# Note that you may also want to add `./configure` options which are used in your# current nginx build.# You can get usually those options using command nginx -V# you can change the parallelism number 2 below to fit the number of spare CPU cores in your# machine. make -j2 make install# Note that this version of lug-nginx-module not allow to set `lua_load_resty_core off;` any more.# So, you have to install `lua-resty-core` and `lua-resty-lrucache` manually as below.cd lua-resty-core make install PREFIX=/opt/nginxcd lua-resty-lrucache make install PREFIX=/opt/nginx# add necessary `lua_package_path` directive to `nginx.conf`, in the http context lua_package_path"/opt/nginx/lib/lua/?.lua;;";

Back to TOC

Starting from NGINX 1.9.11, you can also compile this module as a dynamic module, by using the--add-dynamic-module=PATH option instead of--add-module=PATH on the./configure command line above. And then you can explicitly load the module in yournginx.conf via theload_moduledirective, for example,

load_module /path/to/modules/ndk_http_module.so;  # assuming NDK is built as a dynamic module tooload_module /path/to/modules/ngx_http_lua_module.so;

Back to TOC

While building this module either via OpenResty or with the Nginx core, you can define the following C macros via the C compiler options:

• NGX_LUA_USE_ASSERTWhen defined, will enable assertions in the ngx_lua C code base. Recommended for debugging or testing builds. It can introduce some (small) runtime overhead when enabled. This macro was first introduced in thev0.9.10 release.
• NGX_LUA_ABORT_AT_PANICWhen the LuaJIT VM panics, ngx_lua will instruct the current nginx worker process to quit gracefully by default. By specifying this C macro, ngx_lua will abort the current nginx worker process (which usually results in a core dump file) immediately. This option is useful for debugging VM panics. This option was first introduced in thev0.9.8 release.

To enable one or more of these macros, just pass extra C compiler options to the./configure script of either Nginx or OpenResty. For instance,

./configure --with-cc-opt="-DNGX_LUA_USE_ASSERT -DNGX_LUA_ABORT_AT_PANIC"

Back to TOC

Back to TOC

Theopenresty-en mailing list is for English speakers.

Back to TOC

Theopenresty mailing list is for Chinese speakers.

Back to TOC

The code repository of this project is hosted on GitHub atopenresty/lua-nginx-module.

Back to TOC

Please submit bug reports, wishlists, or patches by

1. creating a ticket on theGitHub Issue Tracker,
2. or posting to theOpenResty community.

Back to TOC

Watch YouTube video "Measure Execution Time of Lua Code Correctly in OpenResty"

As from thev0.5.0rc32 release, all*_by_lua_file configure directives (such ascontent_by_lua_file) support loading LuaJIT 2.0/2.1 raw bytecode files directly:

 /path/to/luajit/bin/luajit -b /path/to/input_file.lua /path/to/output_file.ljbc

The-bg option can be used to include debug information in the LuaJIT bytecode file:

 /path/to/luajit/bin/luajit -bg /path/to/input_file.lua /path/to/output_file.ljbc

Please refer to the official LuaJIT documentation on the-b option for more details:

https://luajit.org/running.html#opt_b

Note that the bytecode files generated by LuaJIT 2.1 isnot compatible withLuaJIT 2.0, and vice versa. The support for LuaJIT 2.1 bytecode was first addedin ngx_lua v0.9.3.

Attempts to load standard Lua 5.1 bytecode files into ngx_lua instances linkedto LuaJIT 2.0/2.1 (or vice versa) will result in an Nginx error message such asthe one below:

[error] 13909#0: *1 failed to load Lua inlined code: bad byte-code header in /path/to/test_file.luac

Loading bytecode files via the Lua primitives likerequire anddofile should always work as expected.

Back to TOC

If you want to access the system environment variable, say,foo, in Lua via the standard Lua APIos.getenv, then you should also list this environment variable name in yournginx.conf file via theenv directive. For example,

env foo;

Back to TOC

The HTTP 1.0 protocol does not support chunked output and requires an explicitContent-Length header when the response body is not empty in order to support the HTTP 1.0 keep-alive.So when a HTTP 1.0 request is made and thelua_http10_buffering directive is turnedon, ngx_lua will buffer theoutput ofngx.say andngx.print calls and also postpone sending response headers until all the response body output is received.At that time ngx_lua can calculate the total length of the body and construct a properContent-Length header to return to the HTTP 1.0 client.If theContent-Length response header is set in the running Lua code, however, this buffering will be disabled even if thelua_http10_buffering directive is turnedon.

For large streaming output responses, it is important to disable thelua_http10_buffering directive to minimise memory usage.

Note that common HTTP benchmark tools such asab andhttp_load issue HTTP 1.0 requests by default.To forcecurl to send HTTP 1.0 requests, use the-0 option.

Back to TOC

With LuaJIT 2.x, it is possible to statically link the bytecode of pure Luamodules into the Nginx executable.

You can use theluajit executable to compile.lua Luamodule files to.o object files containing the exported bytecodedata, and then link the.o files directly in your Nginx build.

Below is a trivial example to demonstrate this. Consider that we have the following.lua file namedfoo.lua:

-- foo.lualocal_M= {}function_M.go()print("Hello from foo")endreturn_M

And then we compile this.lua file tofoo.o file:

 /path/to/luajit/bin/luajit -bg foo.lua foo.o

What matters here is the name of the.lua file, which determines how you use this module later on the Lua land. The file namefoo.o does not matter at all except the.o file extension (which tellsluajit what output format is used). If you want to strip the Lua debug information from the resulting bytecode, you can just specify the-b option above instead of-bg.

Then when building Nginx or OpenResty, pass the--with-ld-opt="foo.o" option to the./configure script:

 ./configure --with-ld-opt="/path/to/foo.o" ...

Finally, you can just do the following in any Lua code run by ngx_lua:

localfoo=require"foo"foo.go()

And this piece of code no longer depends on the externalfoo.lua file any more because it has already been compiled into thenginx executable.

If you want to use dot in the Lua module name when callingrequire, as in

localfoo=require"resty.foo"

then you need to rename thefoo.lua file toresty_foo.lua before compiling it down to a.o file with theluajit command-line utility.

It is important to use exactly the same version of LuaJIT when compiling.lua files to.o files as building nginx + ngx_lua. This is because the LuaJIT bytecode format may be incompatible between different LuaJIT versions. When the bytecode format is incompatible, you will see a Lua runtime error saying that the Lua module is not found.

When you have multiple.lua files to compile and link, then just specify their.o files at the same time in the value of the--with-ld-opt option. For instance,

 ./configure --with-ld-opt="/path/to/foo.o /path/to/bar.o" ...

If you have too many.o files, then it might not be feasible to name them all in a single command. In this case, you can build a static library (or archive) for your.o files, as in

 ar rcus libmyluafiles.a*.o

then you can link themyluafiles archive as a whole to your nginx executable:

 ./configure \     --with-ld-opt="-L/path/to/lib -Wl,--whole-archive -lmyluafiles -Wl,--no-whole-archive"

where/path/to/lib is the path of the directory containing thelibmyluafiles.a file. It should be noted that the linker option--whole-archive is required here because otherwise our archive will be skipped because no symbols in our archive are mentioned in the main parts of the nginx executable.

Back to TOC

To globally share data among all the requests handled by the same Nginx workerprocess, encapsulate the shared data into a Lua module, use the Luarequire builtin to import the module, and then manipulate theshared data in Lua. This works because required Lua modules are loaded onlyonce and all coroutines will share the same copy of the module (both its codeand data).

Note that the use of global Lua variables isstrongly discouraged, as it maylead to unexpected race conditions between concurrent requests.

Here is a small example on sharing data within an Nginx worker via a Lua module:

-- mydata.lualocal_M= {}localdata= {dog=3,cat=4,pig=5, }function_M.get_age(name)returndata[name]endreturn_M

and then accessing it fromnginx.conf:

location /lua{     content_by_lua_block{         local mydata = require"mydata"         ngx.say(mydata.get_age("dog"))}}

Themydata module in this example will only be loaded and run on the first request to the location/lua,and all subsequent requests to the same Nginx worker process will use the reloaded instance of themodule as well as the same copy of the data in it, until aHUP signal is sent to the Nginx master process to force a reload.This data sharing technique is essential for high performance Lua applications based on this module.

Note that this data sharing is on aper-worker basis and not on aper-server basis. That is, when there are multiple Nginx worker processes under an Nginx master, data sharing cannot cross the process boundary between these workers.

It is usually recommended to share read-only data this way. You can also share changeable data among all the concurrent requests of each Nginx worker process aslong as there isno nonblocking I/O operations (includingngx.sleep)in the middle of your calculations. As long as you do not give thecontrol back to the Nginx event loop and ngx_lua's light threadscheduler (even implicitly), there can never be any race conditions inbetween. For this reason, always be very careful when you want to share changeable data on theworker level. Buggy optimizations can easily lead to hard-to-debugrace conditions under load.

If server-wide data sharing is required, then use one or more of the following approaches:

1. Use thengx.shared.DICT API provided by this module.
2. Use only a single Nginx worker and a single server (this is however not recommended when there is a multi core CPU or multiple CPUs in a single machine).
3. Use data storage mechanisms such asmemcached,redis,MySQL orPostgreSQL.The OpenResty official releases come with a set of companion Nginx modules and Lua libraries that provide interfaces with these data storage mechanisms.

Back to TOC

Back to TOC

Thetcpsock:connect method may indicatesuccess despite connection failures such as withConnection Refused errors.

However, later attempts to manipulate the cosocket object will fail and return the actual error status message generated by the failed connect operation.

This issue is due to limitations in the Nginx event model and only appears to affect Mac OS X.

Back to TOC

• Because Lua'sdofile andrequire builtins are currently implemented as C functions in LuaJIT 2.0/2.1, if the Lua file being loaded bydofile orrequire invokesngx.location.capture*,ngx.exec,ngx.exit, or other API functions requiring yielding in thetop-level scope of the Lua file, then the Lua error "attempt to yield across C-call boundary" will be raised. To avoid this, put these calls requiring yielding into your own Lua functions in the Lua file instead of the top-level scope of the file.

Back to TOC

Care must be taken when importing modules, and this form should be used:

localxxx=require('xxx')

instead of the old deprecated form:

require('xxx')

Here is the reason: by design, the global environment has exactly the same lifetime as the Nginx request handler associated with it. Each request handler has its own set of Lua global variables and that is the idea of request isolation. The Lua module is actually loaded by the first Nginx request handler and is cached by therequire() built-in in thepackage.loaded table for later reference, and themodule() builtin used by some Lua modules has the side effect of setting a global variable to the loaded module table. But this global variable will be cleared at the end of the request handler, and every subsequent request handler all has its own (clean) global environment. So one will get Lua exception for accessing thenil value.

The use of Lua global variables is a generally inadvisable in the ngx_lua context as:

1. the misuse of Lua globals has detrimental side effects on concurrent requests when such variables should instead be local in scope,
2. Lua global variables require Lua table look-ups in the global environment which is computationally expensive, and
3. some Lua global variable references may include typing errors which make such difficult to debug.

It is thereforehighly recommended to always declare such within an appropriate local scope instead.

-- Avoidfoo=123-- Recommendedlocalfoo=123-- Avoidfunctionfoo()return123end-- Recommendedlocalfunctionfoo()return123end

To find all instances of Lua global variables in your Lua code, run thelua-releng tool across all.lua source files:

$ lua-relengChecking use of Lua global variables in file lib/foo/bar.lua ...        1       [1489]  SETGLOBAL       7 -1    ; contains        55      [1506]  GETGLOBAL       7 -3    ; setvar        3       [1545]  GETGLOBAL       3 -4    ; varexpand

The output says that the line 1489 of filelib/foo/bar.lua writes to a global variable namedcontains, the line 1506 reads from the global variablesetvar, and line 1545 reads the globalvarexpand.

This tool will guarantee that local variables in the Lua module functions are all declared with thelocal keyword, otherwise a runtime exception will be thrown. It prevents undesirable race conditions while accessing such variables. SeeData Sharing within an Nginx Worker for the reasons behind this.

Back to TOC

Thengx.location.capture andngx.location.capture_multi directives cannot capture locations that include theadd_before_body,add_after_body,auth_request,echo_location,echo_location_async,echo_subrequest, orecho_subrequest_async directives.

location /foo{     content_by_lua_block{         res = ngx.location.capture("/bar")}}location /bar{     echo_location /blah;}location /blah{     echo"Success!";}

 $ curl -ihttp://example.com/foo

will not work as expected.

Back to TOC

Due to internal limitations in the Nginx core, the cosocket API is disabled in the following contexts:set_by_lua*,log_by_lua*,header_filter_by_lua*, andbody_filter_by_lua.

The cosockets are currently also disabled in theinit_by_lua* andinit_worker_by_lua* directive contexts but we may add support for these contexts in the future because there is no limitation in the Nginx core (or the limitation might be worked around).

There exists a workaround, however, when the original context doesnot need to wait for the cosocket results. That is, creating a zero-delay timer via thengx.timer.at API and do the cosocket results in the timer handler, which runs asynchronously as to the original context creating the timer.

Back to TOC

NOTE Following thev0.9.17 release, this pitfall can be avoided by using the*_by_lua_block {} configuration directives.

PCRE sequences such as\d,\s, or\w, require special attention because in string literals, the backslash character,\, is stripped out by both the Lua language parser and by the Nginx config file parser before processing if not within a*_by_lua_block {} directive. So the following snippet will not work as expected:

 # nginx.conf ?location /test{ ?     content_by_lua ' ?         local regex ="\d+"  -- THIS IS WRONG OUTSIDE OF A *_by_lua_block DIRECTIVE ?         local m = ngx.re.match("hello, 1234", regex) ?if m then ngx.say(m[0]) else ngx.say("not matched!") end ?     '; ?} # evaluates to "not matched!"

To avoid this,double escape the backslash:

 # nginx.conflocation /test{     content_by_lua '         local regex ="\\\\d+"         local m = ngx.re.match("hello, 1234", regex)if m then ngx.say(m[0]) else ngx.say("not matched!") end     ';} # evaluates to "1234"

Here,\\\\d+ is stripped down to\\d+ by the Nginx config file parser and this is further stripped down to\d+ by the Lua language parser before running.

Alternatively, the regex pattern can be presented as a long-bracketed Lua string literal by encasing it in "long brackets",[[...]], in which case backslashes have to only be escaped once for the Nginx config file parser.

 # nginx.conflocation /test{     content_by_lua '         local regex = [[\\d+]]         local m = ngx.re.match("hello, 1234", regex)if m then ngx.say(m[0]) else ngx.say("not matched!") end     ';} # evaluates to "1234"

Here,[[\\d+]] is stripped down to[[\d+]] by the Nginx config file parser and this is processed correctly.

Note that a longer from of the long bracket,[=[...]=], may be required if the regex pattern contains[...] sequences.The[=[...]=] form may be used as the default form if desired.

 # nginx.conflocation /test{     content_by_lua '         local regex = [=[[0-9]+]=]         local m = ngx.re.match("hello, 1234", regex)if m then ngx.say(m[0]) else ngx.say("not matched!") end     ';} # evaluates to "1234"

An alternative approach to escaping PCRE sequences is to ensure that Lua code is placed in external script files and executed using the various*_by_lua_file directives.With this approach, the backslashes are only stripped by the Lua language parser and therefore only need to be escaped once each.

-- test.lualocalregex="\\d+"localm=ngx.re.match("hello, 1234",regex)ifmthenngx.say(m[0])elsengx.say("not matched!")end-- evaluates to "1234"

Within external script files, PCRE sequences presented as long-bracketed Lua string literals do not require modification.

-- test.lualocalregex=[[\d+]]localm=ngx.re.match("hello, 1234",regex)ifmthenngx.say(m[0])elsengx.say("not matched!")end-- evaluates to "1234"

As noted earlier, PCRE sequences presented within*_by_lua_block {} directives (available following thev0.9.17 release) do not require modification.

 # nginx.conflocation /test{     content_by_lua_block{         local regex = [[\d+]]         local m = ngx.re.match("hello, 1234", regex)if m then ngx.say(m[0]) else ngx.say("not matched!") end}} # evaluates to "1234"

NOTE You are recommended to useby_lua_file when the Lua code is very long.

Back to TOC

Mixing SSI with ngx_lua in the same Nginx request is not supported at all. Just use ngx_lua exclusively. Everything you can do with SSI can be done atop ngx_lua anyway and it can be more efficient when using ngx_lua.

Back to TOC

Certain Lua APIs provided by ngx_lua do not work in Nginx's SPDY mode yet:ngx.location.capture,ngx.location.capture_multi, andngx.req.socket.

Back to TOC

Nginx may terminate a request early with (at least):

• 400 (Bad Request)
• 405 (Not Allowed)
• 408 (Request Timeout)
• 413 (Request Entity Too Large)
• 414 (Request URI Too Large)
• 494 (Request Headers Too Large)
• 499 (Client Closed Request)
• 500 (Internal Server Error)
• 501 (Not Implemented)

This means that phases that normally run are skipped, such as the rewrite oraccess phase. This also means that later phases that are run regardless, e.g.log_by_lua, will not have access to information that is normally set in thosephases.

Back to TOC

• cosocket: implement LuaSocket's unconnected UDP API.
• cosocket: add support in the context ofinit_by_lua*.
• cosocket: review and merge aviramc'spatch for adding thebsdrecv method.
• cosocket: add configure options for different strategies of handling the cosocket connection exceeding in the pools.
• usengx_hash_t to optimize the built-in header look-up process forngx.req.set_header, and etc.
• addignore_resp_headers,ignore_resp_body, andignore_resp options tongx.location.capture andngx.location.capture_multi methods, to allow micro performance tuning on the user side.
• add automatic Lua code time slicing support by yielding and resuming the Lua VM actively via Lua's debug hooks.
• addstat mode similar tomod_lua.

Back to TOC

The changes made in every release of this module are listed in the change logs of the OpenResty bundle:

https://openresty.org/#Changes

Back to TOC

This module uses.travis.yml as the CI configuration.You can always check.travis.yml for the latest CI configuration.

For developers, you need to run tests locally. You can useutil/run-ci.shto easily set up the environment and execute the test suite.

To run the Test from the beginning:

git clone https://github.com/openresty/lua-nginx-module.gitcd lua-nginx-modulebash util/run-ci.sh

The following dependencies are required to run the test suite:

• Nginx version >= 1.4.2

• Perl modules:

  • Test::Nginx:https://github.com/openresty/test-nginx

• Nginx modules:

  • ngx_devel_kit
  • ngx_set_misc
  • ngx_auth_request (this is not needed if you're using Nginx 1.5.4+.
  • ngx_echo
  • ngx_memc
  • ngx_srcache
  • ngx_lua (i.e., this module)
  • ngx_lua_upstream
  • ngx_headers_more
  • ngx_drizzle
  • ngx_rds_json
  • ngx_coolkit
  • ngx_redis2

The order in which these modules are added during configuration is important because the position of any filter module in thefiltering chain determines the final output, for example. The correct adding order is shown above.

• 3rd-party Lua libraries:

  • lua-cjson

• Applications:

  • mysql: create database 'ngx_test', grant all privileges to user 'ngx_test', password is 'ngx_test'
  • memcached: listening on the default port, 11211.
  • redis: listening on the default port, 6379.

See also thedeveloper build script for more details on setting up the testing environment.

To run the whole test suite in the default testing mode:

cd /path/to/lua-nginx-moduleexport PATH=/path/to/your/nginx/sbin:$PATHprove -I/path/to/test-nginx/lib -r t

To run specific test files:

cd /path/to/lua-nginx-moduleexport PATH=/path/to/your/nginx/sbin:$PATHprove -I/path/to/test-nginx/lib t/002-content.t t/003-errors.t

To run a specific test block in a particular test file, add the line--- ONLY to the test block you want to run, and then use theprove utility to run that.t file.

There are also various testing modes based on mockeagain, valgrind, and etc. Refer to theTest::Nginx documentation for more details for various advanced testing modes. See also the test reports for the Nginx test cluster running on Amazon EC2:https://qa.openresty.org.

Back to TOC

This module is licensed under the BSD license.

Copyright (C) 2009-2017, by Xiaozhe Wang (chaoslawful)chaoslawful@gmail.com.

Copyright (C) 2009-2019, by Yichun "agentzh" Zhang (章亦春)agentzh@gmail.com, OpenResty Inc.

All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

• Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

• Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Back to TOC

Blog posts:

• Introduction to Lua-Land CPU Flame Graphs
• How OpenResty and Nginx Allocate and Manage Memory
• How OpenResty and Nginx Shared Memory Zones Consume RAM
• Memory Fragmentation in OpenResty and Nginx's Shared Memory Zones

Other related modules and libraries:

• ngx_stream_lua_module for an official port of this module for the Nginx "stream" subsystem (doing generic downstream TCP communications).
• lua-resty-memcached library based on ngx_lua cosocket.
• lua-resty-redis library based on ngx_lua cosocket.
• lua-resty-mysql library based on ngx_lua cosocket.
• lua-resty-upload library based on ngx_lua cosocket.
• lua-resty-dns library based on ngx_lua cosocket.
• lua-resty-websocket library for both WebSocket server and client, based on ngx_lua cosocket.
• lua-resty-string library based onLuaJIT FFI.
• lua-resty-lock library for a nonblocking simple lock API.
• lua-resty-cookie library for HTTP cookie manipulation.
• Routing requests to different MySQL queries based on URI arguments
• Dynamic Routing Based on Redis and Lua
• Using LuaRocks with ngx_lua
• Introduction to ngx_lua
• ngx_devel_kit
• echo-nginx-module
• drizzle-nginx-module
• postgres-nginx-module
• memc-nginx-module
• The OpenResty bundle
• Nginx Systemtap Toolkit

Back to TOC

• lua_load_resty_core
• lua_capture_error_log
• lua_use_default_type
• lua_malloc_trim
• lua_code_cache
• lua_thread_cache_max_entries
• lua_regex_cache_max_entries
• lua_regex_match_limit
• lua_package_path
• lua_package_cpath
• init_by_lua
• init_by_lua_block
• init_by_lua_file
• init_worker_by_lua
• init_worker_by_lua_block
• init_worker_by_lua_file
• exit_worker_by_lua_block
• exit_worker_by_lua_file
• set_by_lua
• set_by_lua_block
• set_by_lua_file
• content_by_lua
• content_by_lua_block
• content_by_lua_file
• server_rewrite_by_lua_block
• server_rewrite_by_lua_file
• rewrite_by_lua
• rewrite_by_lua_block
• rewrite_by_lua_file
• access_by_lua
• access_by_lua_block
• access_by_lua_file
• header_filter_by_lua
• header_filter_by_lua_block
• header_filter_by_lua_file
• body_filter_by_lua
• body_filter_by_lua_block
• body_filter_by_lua_file
• log_by_lua
• log_by_lua_block
• log_by_lua_file
• balancer_by_lua_block
• balancer_by_lua_file
• balancer_keepalive
• lua_need_request_body
• ssl_client_hello_by_lua_block
• ssl_client_hello_by_lua_file
• ssl_certificate_by_lua_block
• ssl_certificate_by_lua_file
• ssl_session_fetch_by_lua_block
• ssl_session_fetch_by_lua_file
• ssl_session_store_by_lua_block
• ssl_session_store_by_lua_file
• lua_shared_dict
• lua_socket_connect_timeout
• lua_socket_send_timeout
• lua_socket_send_lowat
• lua_socket_read_timeout
• lua_socket_buffer_size
• lua_socket_pool_size
• lua_socket_keepalive_timeout
• lua_socket_log_errors
• lua_ssl_ciphers
• lua_ssl_crl
• lua_ssl_protocols
• lua_ssl_certificate
• lua_ssl_certificate_key
• lua_ssl_trusted_certificate
• lua_ssl_verify_depth
• lua_ssl_key_log
• lua_ssl_conf_command
• lua_http10_buffering
• rewrite_by_lua_no_postpone
• access_by_lua_no_postpone
• lua_transform_underscores_in_response_headers
• lua_check_client_abort
• lua_max_pending_timers
• lua_max_running_timers
• lua_sa_restart
• lua_worker_thread_vm_pool_size

The basic building blocks of scripting Nginx with Lua are directives. Directives are used to specify when the user Lua code is run andhow the result will be used. Below is a diagram showing the order in which directives are executed.

Back to TOC

syntax:lua_load_resty_core on|off

default:lua_load_resty_core on

context:http

This directive is deprecated since thev0.10.16 release of thismodule. Theresty.core module fromlua-resty-core is now mandatorilyloaded during the Lua VM initialization. Specifying this directive will have noeffect.

This directive was first introduced in thev0.10.15 release andused to optionally load theresty.core module.

Back to TOC

syntax:lua_capture_error_log size

default:none

context:http

Enables a buffer of the specifiedsize for capturing all the Nginx error log message data (not just those producedby this module or the Nginx http subsystem, but everything) without touching files or disks.

You can use units likek andm in thesize value, as in

 lua_capture_error_log100k;

As a rule of thumb, a 4KB buffer can usually hold about 20 typical error log messages. So do the maths!

This buffer never grows. If it is full, new error log messages will replace the oldest ones in the buffer.

The size of the buffer must be bigger than the maximum length of a single error log message (which is 4K in OpenResty and 2K in stock NGINX).

You can read the messages in the buffer on the Lua land via theget_logs()function of thengx.errlogmodule of thelua-resty-corelibrary. This Lua API function will return the captured error log messages andalso remove these already read from the global capturing buffer, making roomfor any new error log data. For this reason, the user should not configure thisbuffer to be too big if the user read the buffered error log data fast enough.

Note that the log level specified in the standarderror_log directivedoes have effect on this capturing facility. It only captures logmessages of a level no lower than the specified log level in theerror_log directive.The user can still choose to set an even higher filtering log level on the fly via the Lua API functionerrlog.set_filter_level.So it is more flexible than the staticerror_log directive.

It is worth noting that there is no way to capture the debugging logswithout building OpenResty or Nginx with the./configureoption--with-debug. And enabling debugging logs isstrongly discouraged in production builds due to high overhead.

This directive was first introduced in thev0.10.9 release.

Back to TOC

syntax:lua_use_default_type on | off

default:lua_use_default_type on

context:http, server, location, location if

Specifies whether to use the MIME type specified by thedefault_type directive for the default value of theContent-Type response header. Deactivate this directive if a defaultContent-Type response header for Lua request handlers is not desired.

This directive is turned on by default.

This directive was first introduced in thev0.9.1 release.

Back to TOC

syntax:lua_malloc_trim <request-count>

default:lua_malloc_trim 1000

context:http

Asks the underlyinglibc runtime library to release its cached free memory back to the operating system everyN requests processed by the Nginx core. By default,N is 1000. You can configure the request countby using your own numbers. Smaller numbers mean more frequent releases, which may introduce higher CPU time consumption andsmaller memory footprint while larger numbers usually lead to less CPU time overhead and relatively larger memory footprint.Just tune the number for your own use cases.

Configuring the argument to0 essentially turns off the periodical memory trimming altogether.

 lua_malloc_trim 0;  # turn off trimming completely

The current implementation uses an Nginx log phase handler to do the request counting. So the appearance of thelog_subrequest on directives innginx.confmay make the counting faster when subrequests are involved. By default, only "main requests" count.

Note that this directive doesnot affect the memory allocated by LuaJIT's own allocator based on themmapsystem call.

This directive was first introduced in thev0.10.7 release.

Back to TOC

syntax:lua_code_cache on | off

default:lua_code_cache on

context:http, server, location, location if

Enables or disables the Lua code cache for Lua code in*_by_lua_file directives (likeset_by_lua_file andcontent_by_lua_file) and Lua modules.

When turning off, every request served by ngx_lua will run in a separate Lua VM instance, starting from the0.9.3 release. So the Lua files referenced inset_by_lua_file,content_by_lua_file,access_by_lua_file,and etc will not be cachedand all Lua modules used will be loaded from scratch. With this in place, developers can adopt an edit-and-refresh approach.

Please note however, that Lua code written inlined within nginx.confsuch as those specified byset_by_lua,content_by_lua,access_by_lua, andrewrite_by_lua will not be updated when you edit the inlined Lua code in yournginx.conf file because only the Nginx config file parser can correctly parse thenginx.conffile and the only way is to reload the config fileby sending aHUP signal or just to restart Nginx.

Even when the code cache is enabled, Lua files which are loaded bydofile orloadfilein *_by_lua_file cannot be cached (unless you cache the results yourself). Usually you can either use theinit_by_luaorinit_by_lua_file directives to load all such files or just make these Lua files true Lua modulesand load them viarequire.

The ngx_lua module does not support thestat mode available with theApachemod_lua module (yet).

Disabling the Lua code cache is stronglydiscouraged for production use and should only be used duringdevelopment as it has a significant negative impact on overall performance. For example, the performance of a "hello world" Lua example can drop by an order of magnitude after disabling the Lua code cache.

Back to TOC

syntax:lua_thread_cache_max_entries <num>

default:lua_thread_cache_max_entries 1024

context:http

Specifies the maximum number of entries allowed in the worker process level lua thread object cache.

This cache recycles the lua thread GC objects among all our "light threads".

A zero value of<num> disables the cache.

Note that this feature requires OpenResty's LuaJIT with the new C APIlua_resetthread.

This feature was first introduced in versonv0.10.9.

Back to TOC

syntax:lua_regex_cache_max_entries <num>

default:lua_regex_cache_max_entries 1024

context:http

Specifies the maximum number of entries allowed in the worker process level compiled regex cache.

The regular expressions used inngx.re.match,ngx.re.gmatch,ngx.re.sub, andngx.re.gsub will be cached within this cache if the regex optiono (i.e., compile-once flag) is specified.

The default number of entries allowed is 1024 and when this limit is reached, new regular expressions will not be cached (as if theo option was not specified) and there will be one, and only one, warning in theerror.log file:

2011/08/27 23:18:26 [warn] 31997#0: *1 lua exceeding regex cache max entries (1024), ...

If you are using thengx.re.* implementation oflua-resty-core by loading theresty.core.regex module (or just theresty.core module), then an LRU cache is used for the regex cache being used here.

Do not activate theo option for regular expressions (and/orreplace string arguments forngx.re.sub andngx.re.gsub) that are generatedon the fly and give rise to infinite variations to avoid hitting the specified limit.

Back to TOC

syntax:lua_regex_match_limit <num>

default:lua_regex_match_limit 0

context:http

Specifies the "match limit" used by the PCRE library when executing thengx.re API. To quote the PCRE manpage, "the limit ... has the effect of limiting the amount of backtracking that can take place."

When the limit is hit, the error string "pcre_exec() failed: -8" will be returned by thengx.re API functions on the Lua land.

When setting the limit to 0, the default "match limit" when compiling the PCRE library is used. And this is the default value of this directive.

This directive was first introduced in thev0.8.5 release.

Back to TOC

syntax:lua_package_path <lua-style-path-str>

default:The content of LUA_PATH environment variable or Lua's compiled-in defaults.

context:http

Sets the Lua module search path used by scripts specified byset_by_lua,content_by_lua and others. The path string is in standard Lua path form, and;;can be used to stand for the original search paths.

As from thev0.5.0rc29 release, the special notation$prefix or${prefix} can be used in the search path string to indicate the path of theserver prefix usually determined by the-p PATH command-line option while starting the Nginx server.

Back to TOC

syntax:lua_package_cpath <lua-style-cpath-str>

default:The content of LUA_CPATH environment variable or Lua's compiled-in defaults.

context:http

Sets the Lua C-module search path used by scripts specified byset_by_lua,content_by_lua and others. The cpath string is in standard Lua cpath form, and;;can be used to stand for the original cpath.

As from thev0.5.0rc29 release, the special notation$prefix or${prefix} can be used in the search path string to indicate the path of theserver prefix usually determined by the-p PATH command-line option while starting the Nginx server.

Back to TOC

syntax:init_by_lua <lua-script-str>

context:http

phase:loading-config

NOTE Use of this directive isdiscouraged following thev0.9.17 release. Use theinit_by_lua_block directive instead.

Similar to theinit_by_lua_block directive, but accepts the Lua source directly in an Nginx string literal (which requiresspecial character escaping).

For instance,

 init_by_lua '     print("I need no extra escaping here, for example:\r\nblah") '

This directive was first introduced in thev0.5.5 release.

Back to TOC

syntax:init_by_lua_block { lua-script }

context:http

phase:loading-config

When Nginx receives theHUP signal and starts reloading the config file, the Lua VM will also be re-created andinit_by_lua_block will run again on the new Lua VM. In case that thelua_code_cache directive is turned off (default on), theinit_by_lua_block handler will run upon every request because in this special mode a standalone Lua VM is always created for each request.

Usually you can pre-load Lua modules at server start-up by means of this hook and take advantage of modern operating systems' copy-on-write (COW) optimization. Here is an example for pre-loading Lua modules:

 # this runs before forking out nginx worker processes: init_by_lua_block{ require"cjson"}server{location = /api{         content_by_lua_block{             -- the following require() will justreturn             -- the already loaded module from package.loaded:             ngx.say(require"cjson".encode{dog = 5, cat = 6})}}}

You can also initialize thelua_shared_dict shm storage at this phase. Here is an example for this:

 lua_shared_dict dogs1m; init_by_lua_block{     local dogs = ngx.shared.dogs     dogs:set("Tom",56)}server{location = /api{         content_by_lua_block{             local dogs = ngx.shared.dogs             ngx.say(dogs:get("Tom"))}}}

But note that, thelua_shared_dict's shm storage will not be cleared through a config reload (via theHUP signal, for example). So if you donot want to re-initialize the shm storage in yourinit_by_lua_block code in this case, then you just need to set a custom flag in the shm storage and always check the flag in yourinit_by_lua_block code.

Because the Lua code in this context runs before Nginx forks its worker processes (if any), data or code loaded here will enjoy theCopy-on-write (COW) feature provided by many operating systems among all the worker processes, thus saving a lot of memory.

Donot initialize your own Lua global variables in this context because use of Lua global variables have performance penalties and can lead to global namespace pollution (see theLua Variable Scope section for more details). The recommended way is to use properLua module files (but do not use the standard Lua functionmodule() to define Lua modules because it pollutes the global namespace as well) and callrequire() to load your own module files ininit_by_lua_block or other contexts (require() does cache the loaded Lua modules in the globalpackage.loaded table in the Lua registry so your modules will only loaded once for the whole Lua VM instance).

Only a small set of theNginx API for Lua is supported in this context:

• Logging APIs:ngx.log andprint,
• Shared Dictionary API:ngx.shared.DICT.

More Nginx APIs for Lua may be supported in this context upon future user requests.

Basically you can safely use Lua libraries that do blocking I/O in this very context because blocking the master process during server start-up is completely okay. Even the Nginx core does blocking I/O (at least on resolving upstream's host names) at the configure-loading phase.

You should be very careful about potential security vulnerabilities in your Lua code registered in this context because the Nginx master process is often run under theroot account.

This directive was first introduced in thev0.9.17 release.

See also the following blog posts for more details on OpenResty and Nginx's shared memory zones:

• How OpenResty and Nginx Shared Memory Zones Consume RAM
• Memory Fragmentation in OpenResty and Nginx's Shared Memory Zones

Back to TOC

syntax:init_by_lua_file <path-to-lua-script-file>

context:http

phase:loading-config

Equivalent toinit_by_lua_block, except that the file specified by<path-to-lua-script-file> contains the Lua code orLuaJIT bytecode to be executed.

When a relative path likefoo/bar.lua is given, they will be turned into the absolute path relative to theserver prefix path determined by the-p PATH command-line option while starting the Nginx server.

This directive was first introduced in thev0.5.5 release.

Back to TOC

syntax:init_worker_by_lua <lua-script-str>

context:http

phase:starting-worker

NOTE Use of this directive isdiscouraged following thev0.9.17 release. Use theinit_worker_by_lua_block directive instead.

Similar to theinit_worker_by_lua_block directive, but accepts the Lua source directly in an Nginx string literal (which requiresspecial character escaping).

For instance,

 init_worker_by_lua '     print("I need no extra escaping here, for example:\r\nblah") ';

This directive was first introduced in thev0.9.5 release.

This hook no longer runs in the cache manager and cache loader processes since thev0.10.12 release.

Back to TOC

syntax:init_worker_by_lua_block { lua-script }

context:http

phase:starting-worker

Runs the specified Lua code upon every Nginx worker process's startup when the master process is enabled. When the master process is disabled, this hook will just run afterinit_by_lua*.

This hook is often used to create per-worker reoccurring timers (via thengx.timer.at Lua API), either for backend health-check or other timed routine work. Below is an example,

 init_worker_by_lua_block{     local delay = 3  -- in seconds     local new_timer = ngx.timer.at     local log = ngx.log     local ERR = ngx.ERR     local check     check = function(premature)if not premature then             -- do the health check or other routine work             local ok, err = new_timer(delay, check)if not ok then                 log(ERR,"failed to create timer: ", err)return             end         end         -- do something in timer     end     local hdl, err = new_timer(delay, check)if not hdl then         log(ERR,"failed to create timer: ", err)return     end     -- other job in init_worker_by_lua}

This directive was first introduced in thev0.9.17 release.

This hook no longer runs in the cache manager and cache loader processes since thev0.10.12 release.

Back to TOC

syntax:init_worker_by_lua_file <lua-file-path>

context:http

phase:starting-worker

Similar toinit_worker_by_lua_block, but accepts the file path to a Lua source file or Lua bytecode file.

This directive was first introduced in thev0.9.5 release.

This hook no longer runs in the cache manager and cache loader processes since thev0.10.12 release.

Back to TOC

syntax:exit_worker_by_lua_block { lua-script }

context:http

phase:exiting-worker

Runs the specified Lua code upon every Nginx worker process's exit when the master process is enabled. When the master process is disabled, this hook will run before the Nginx process exits.

This hook is often used to release resources allocated by each worker (e.g. resources allocated byinit_worker_by_lua*), or to prevent workers from exiting abnormally.

For example,

 exit_worker_by_lua_block{     print("log from exit_worker_by_lua_block")}

It's not allowed to create a timer (even a 0-delay timer) here since it runs after all timers have been processed.

This directive was first introduced in thev0.10.18 release.

Back to TOC

syntax:exit_worker_by_lua_file <path-to-lua-script-file>

context:http

phase:exiting-worker

Similar toexit_worker_by_lua_block, but accepts the file path to a Lua source file or Lua bytecode file.

This directive was first introduced in thev0.10.18 release.

Back to TOC

syntax:set_by_lua $res <lua-script-str> [$arg1 $arg2 ...]

context:server, server if, location, location if

phase:rewrite

NOTE Use of this directive isdiscouraged following thev0.9.17 release. Use theset_by_lua_block directive instead.

Similar to theset_by_lua_block directive, but accepts the Lua source directly in an Nginx string literal (which requiresspecial character escaping), and

1. this directive support extra arguments after the Lua script.

For example,

 set_by_lua$res' return 32 + math.cos(32) '; # $res now has the value "32.834223360507" or alike.

As from thev0.5.0rc29 release, Nginx variable interpolation is disabled in the<lua-script-str> argument of this directive and therefore, the dollar sign character ($) can be used directly.

This directive requires thengx_devel_kit module.

Back to TOC

syntax:set_by_lua_block $res { lua-script }

context:server, server if, location, location if

phase:rewrite

Executes code specified inside a pair of curly braces ({}), and returns string output to$res.The code inside a pair of curly braces ({}) can makeAPI calls and can retrieve input arguments from thengx.arg table (index starts from1 and increases sequentially).

This directive is designed to execute short, fast running code blocks as the Nginx event loop is blocked during code execution. Time consuming code sequences should therefore be avoided.

This directive is implemented by injecting custom commands into the standardngx_http_rewrite_module's command list. Becausengx_http_rewrite_module does not support nonblocking I/O in its commands, Lua APIs requiring yielding the current Lua "light thread" cannot work in this directive.

At least the following API functions are currently disabled within the context ofset_by_lua_block:

• Output API functions (e.g.,ngx.say andngx.send_headers)
• Control API functions (e.g.,ngx.exit)
• Subrequest API functions (e.g.,ngx.location.capture andngx.location.capture_multi)
• Cosocket API functions (e.g.,ngx.socket.tcp andngx.req.socket).
• Sleeping API functionngx.sleep.

In addition, note that this directive can only write out a value to a single Nginx variable ata time. However, a workaround is possible using thengx.var.VARIABLE interface.

location /foo{set$diff''; # we have to predefine the$diff variable here     set_by_lua_block$sum{         local a =32         local b =56         ngx.var.diff = a - b  -- write to$diff directlyreturn a + b          --return the$sum value normally}     echo"sum = $sum, diff = $diff";}

This directive can be freely mixed with all directives of thengx_http_rewrite_module,set-misc-nginx-module, andarray-var-nginx-module modules. All of these directives will run in the same order as they appear in the config file.

set$foo32; set_by_lua_block$bar{return tonumber(ngx.var.foo) + 1}set$baz"bar: $bar";  #$baz =="bar: 33"

No special escaping is required in the Lua code block.

This directive requires thengx_devel_kit module.

This directive was first introduced in thev0.9.17 release.

Back to TOC

syntax:set_by_lua_file $res <path-to-lua-script-file> [$arg1 $arg2 ...]

context:server, server if, location, location if

phase:rewrite

Equivalent toset_by_lua_block, except that the file specified by<path-to-lua-script-file> contains the Lua code, or, as from thev0.5.0rc32 release, theLuaJIT bytecode to be executed.

Nginx variable interpolation is supported in the<path-to-lua-script-file> argument string of this directive. But special care must be taken for injection attacks.

When a relative path likefoo/bar.lua is given, they will be turned into the absolute path relative to theserver prefix path determined by the-p PATH command-line option while starting the Nginx server.

When the Lua code cache is turned on (by default), the user code is loaded once at the first request and cachedand the Nginx config must be reloaded each time the Lua source file is modified.The Lua code cache can be temporarily disabled during development byswitchinglua_code_cacheoff innginx.conf to avoid reloading Nginx.

This directive requires thengx_devel_kit module.

Back to TOC

syntax:content_by_lua <lua-script-str>

context:location, location if

phase:content

NOTE Use of this directive isdiscouraged following thev0.9.17 release. Use thecontent_by_lua_block directive instead.

Similar to thecontent_by_lua_block directive, but accepts the Lua source directly in an Nginx string literal (which requiresspecial character escaping).

For instance,

 content_by_lua '     ngx.say("I need no extra escaping here, for example:\r\nblah") ';

Back to TOC

syntax:content_by_lua_block { lua-script }

context:location, location if

phase:content

For instance,

 content_by_lua_block{     ngx.say("I need no extra escaping here, for example:\r\nblah")}

Acts as a "content handler" and executes Lua code string specified in{ lua-script } for every request.The Lua code may makeAPI calls and is executed as a new spawned coroutine in an independent global environment (i.e. a sandbox).

Do not use this directive and other content handler directives in the same location. For example, this directive and theproxy_pass directive should not be used in the same location.

This directive was first introduced in thev0.9.17 release.

Back to TOC

syntax:content_by_lua_file <path-to-lua-script-file>

context:location, location if

phase:content

Equivalent tocontent_by_lua_block, except that the file specified by<path-to-lua-script-file> contains the Lua code, or, as from thev0.5.0rc32 release, theLuaJIT bytecode to be executed.

If the file is not found, a404 Not Found status code will be returned, and a503 Service Temporarily Unavailable status code will be returned in case of errors in reading other files.

Nginx variables can be used in the<path-to-lua-script-file> string to provide flexibility. This however carries some risks and is not ordinarily recommended.

When a relative path likefoo/bar.lua is given, they will be turned into the absolute path relative to theserver prefix path determined by the-p PATH command-line option while starting the Nginx server.

When the Lua code cache is turned on (by default), the user code is loaded once at the first request and cachedand the Nginx config must be reloaded each time the Lua source file is modified.The Lua code cache can be temporarily disabled during development byswitchinglua_code_cacheoff innginx.conf to avoid reloading Nginx.

Nginx variables are supported in the file path for dynamic dispatch, for example:

 # CAUTION: contents in nginx var must be carefully filtered, # otherwise there'll be great security risk!location~ ^/app/([-_a-zA-Z0-9/]+){set$path$1;     content_by_lua_file /path/to/lua/app/root/$path.lua;}

But be very careful about malicious user inputs and always carefully validate or filter out the user-supplied path components.

Back to TOC

syntax:server_rewrite_by_lua_block { lua-script }

context:http, server

phase:server rewrite

Acts as a server rewrite phase handler and executes Lua code string specified in{ lua-script } for every request.The Lua code may makeAPI calls and is executed as a new spawned coroutine in an independent global environment (i.e. a sandbox).

server{     ...     server_rewrite_by_lua_block{         ngx.ctx.a ="server_rewrite_by_lua_block in http"}location /lua{         content_by_lua_block{             ngx.say(ngx.ctx.a)             ngx.log(ngx.INFO, ngx.ctx.a)}}}

Just as any other rewrite phase handlers,server_rewrite_by_lua_block also runs in subrequests.

server{     server_rewrite_by_lua_block{         ngx.log(ngx.INFO,"is_subrequest:", ngx.is_subrequest)}location /lua{         content_by_lua_block{             local res = ngx.location.capture("/sub")             ngx.print(res.body)}}location /sub{         content_by_lua_block{             ngx.say("OK")}}}

Note that when callingngx.exit(ngx.OK) within aserver_rewrite_by_lua_block handler, the Nginx request processing control flow will still continue to the content handler. To terminate the current request from within aserver_rewrite_by_lua_block handler, callngx.exit with status >= 200 (ngx.HTTP_OK) and status < 300 (ngx.HTTP_SPECIAL_RESPONSE) for successful quits andngx.exit(ngx.HTTP_INTERNAL_SERVER_ERROR) (or its friends) for failures.

 server_rewrite_by_lua_block{     ngx.exit(503)}location /bar{     ...     # never exec}

Back to TOC

syntax:server_rewrite_by_lua_file <path-to-lua-script-file>

context:http, server

phase:server rewrite

Equivalent toserver_rewrite_by_lua_block, except that the file specified by<path-to-lua-script-file> contains the Lua code, or, as from thev0.10.22 release, theLuaJIT bytecode to be executed.

Nginx variables can be used in the<path-to-lua-script-file> string to provide flexibility. This however carries some risks and is not ordinarily recommended.

When a relative path likefoo/bar.lua is given, they will be turned into the absolute path relative to theserver prefix path determined by the-p PATH command-line option while starting the Nginx server.

When the Lua code cache is turned on (by default), the user code is loaded once at the first request and cached and the Nginx config must be reloaded each time the Lua source file is modified. The Lua code cache can be temporarily disabled during development by switchinglua_code_cacheoff innginx.conf to avoid reloading Nginx.

Back to TOC

syntax:rewrite_by_lua <lua-script-str>

context:http, server, location, location if

phase:rewrite tail

NOTE Use of this directive isdiscouraged following thev0.9.17 release. Use therewrite_by_lua_block directive instead.

Similar to therewrite_by_lua_block directive, but accepts the Lua source directly in an Nginx string literal (which requiresspecial character escaping).

For instance,

 rewrite_by_lua '     do_something("hello, world!\nhiya\n") ';

Back to TOC

syntax:rewrite_by_lua_block { lua-script }

context:http, server, location, location if

phase:rewrite tail

Acts as a rewrite phase handler and executes Lua code string specified in{ lua-script } for every request.The Lua code may makeAPI calls and is executed as a new spawned coroutine in an independent global environment (i.e. a sandbox).

Note that this handler always runsafter the standardngx_http_rewrite_module. So the following will work as expected:

location /foo{set$a12; # create and initialize$aset$b""; # create and initialize$b     rewrite_by_lua_block{         ngx.var.b = tonumber(ngx.var.a) + 1}     echo"res = $b";}

becauseset $a 12 andset $b "" runbeforerewrite_by_lua_block.

On the other hand, the following will not work as expected:

 ?location /foo{ ?set$a12; # create and initialize$a ?set$b''; # create and initialize$b ?      rewrite_by_lua_block{ ?          ngx.var.b = tonumber(ngx.var.a) + 1 ?} ?if($b ='13'){ ?rewrite ^ /bar redirect; ?break; ?} ? ?      echo"res = $b"; ?}

becauseif runsbeforerewrite_by_lua_block even if it is placed afterrewrite_by_lua_block in the config.

The right way of doing this is as follows:

location /foo{set$a12; # create and initialize$aset$b''; # create and initialize$b     rewrite_by_lua_block{         ngx.var.b = tonumber(ngx.var.a) + 1if tonumber(ngx.var.b) ==13 thenreturn ngx.redirect("/bar")         end}     echo"res = $b";}

Note that thengx_eval module can be approximated by usingrewrite_by_lua_block. For example,

location /{     eval$res{proxy_passhttp://foo.com/check-spam;}if($res ='spam'){rewrite ^ /terms-of-use.html redirect;}fastcgi_pass ...;}

can be implemented in ngx_lua as:

location = /check-spam{internal;proxy_passhttp://foo.com/check-spam;}location /{     rewrite_by_lua_block{         local res = ngx.location.capture("/check-spam")if res.body =="spam" thenreturn ngx.redirect("/terms-of-use.html")         end}fastcgi_pass ...;}

Just as any other rewrite phase handlers,rewrite_by_lua_block also runs in subrequests.

Note that when callingngx.exit(ngx.OK) within arewrite_by_lua_block handler, the Nginx request processing control flow will still continue to the content handler. To terminate the current request from within arewrite_by_lua_block handler, callngx.exit with status >= 200 (ngx.HTTP_OK) and status < 300 (ngx.HTTP_SPECIAL_RESPONSE) for successful quits andngx.exit(ngx.HTTP_INTERNAL_SERVER_ERROR) (or its friends) for failures.

If thengx_http_rewrite_module'srewrite directive is used to change the URI and initiate location re-lookups (internal redirections), then anyrewrite_by_lua_block orrewrite_by_lua_file_block code sequences within the current location will not be executed. For example,

location /foo{rewrite ^ /bar;     rewrite_by_lua_block{         ngx.exit(503)}}location /bar{     ...}

Here the Lua codengx.exit(503) will never run. This will be the case ifrewrite ^ /bar last is used as this will similarly initiate an internal redirection. If thebreak modifier is used instead, there will be no internal redirection and therewrite_by_lua_block code will be executed.

Therewrite_by_lua_block code will always run at the end of therewrite request-processing phase unlessrewrite_by_lua_no_postpone is turned on.

This directive was first introduced in thev0.9.17 release.

Back to TOC

syntax:rewrite_by_lua_file <path-to-lua-script-file>

context:http, server, location, location if

phase:rewrite tail

Equivalent torewrite_by_lua_block, except that the file specified by<path-to-lua-script-file> contains the Lua code, or, as from thev0.5.0rc32 release, theLuaJIT bytecode to be executed.

Nginx variables can be used in the<path-to-lua-script-file> string to provide flexibility. This however carries some risks and is not ordinarily recommended.

When a relative path likefoo/bar.lua is given, they will be turned into the absolute path relative to theserver prefix path determined by the-p PATH command-line option while starting the Nginx server.

When the Lua code cache is turned on (by default), the user code is loaded once at the first request and cached and the Nginx config must be reloaded each time the Lua source file is modified. The Lua code cache can be temporarily disabled during development by switchinglua_code_cacheoff innginx.conf to avoid reloading Nginx.

Therewrite_by_lua_file code will always run at the end of therewrite request-processing phase unlessrewrite_by_lua_no_postpone is turned on.

Nginx variables are supported in the file path for dynamic dispatch just as incontent_by_lua_file.

Back to TOC

syntax:access_by_lua <lua-script-str>

context:http, server, location, location if

phase:access tail

NOTE Use of this directive isdiscouraged following thev0.9.17 release. Use theaccess_by_lua_block directive instead.

Similar to theaccess_by_lua_block directive, but accepts the Lua source directly in an Nginx string literal (which requiresspecial character escaping).

For instance,

 access_by_lua '     do_something("hello, world!\nhiya\n") ';

Back to TOC

syntax:access_by_lua_block { lua-script }

context:http, server, location, location if

phase:access tail

Acts as an access phase handler and executes Lua code string specified in{ <lua-script } for every request.The Lua code may makeAPI calls and is executed as a new spawned coroutine in an independent global environment (i.e. a sandbox).

Note that this handler always runsafter the standardngx_http_access_module. So the following will work as expected:

location /{deny192.168.1.1;allow192.168.1.0/24;allow10.1.1.0/16;deny    all;     access_by_lua_block{         local res = ngx.location.capture("/mysql",{ ...})         ...}     # proxy_pass/fastcgi_pass/...}

That is, if a client IP address is in the blacklist, it will be denied before the MySQL query for more complex authentication is executed byaccess_by_lua_block.

Note that thengx_auth_request module can be approximated by usingaccess_by_lua_block:

location /{auth_request /auth;     # proxy_pass/fastcgi_pass/postgres_pass/...}

can be implemented in ngx_lua as:

location /{     access_by_lua_block{         local res = ngx.location.capture("/auth")if res.status == ngx.HTTP_OK thenreturn         endif res.status == ngx.HTTP_FORBIDDEN then             ngx.exit(res.status)         end         ngx.exit(ngx.HTTP_INTERNAL_SERVER_ERROR)}     # proxy_pass/fastcgi_pass/postgres_pass/...}

As with other access phase handlers,access_by_lua_block willnot run in subrequests.

Note that when callingngx.exit(ngx.OK) within aaccess_by_lua_block handler, the Nginx request processing control flow will still continue to the content handler. To terminate the current request from within aaccess_by_lua_block handler, callngx.exit with status >= 200 (ngx.HTTP_OK) and status < 300 (ngx.HTTP_SPECIAL_RESPONSE) for successful quits andngx.exit(ngx.HTTP_INTERNAL_SERVER_ERROR) (or its friends) for failures.

Starting from thev0.9.20 release, you can use theaccess_by_lua_no_postponedirective to control when to run this handler inside the "access" request-processing phaseof Nginx.

This directive was first introduced in thev0.9.17 release.

Back to TOC

syntax:access_by_lua_file <path-to-lua-script-file>

context:http, server, location, location if

phase:access tail

Equivalent toaccess_by_lua_block, except that the file specified by<path-to-lua-script-file> contains the Lua code, or, as from thev0.5.0rc32 release, theLuaJIT bytecode to be executed.

Nginx variables can be used in the<path-to-lua-script-file> string to provide flexibility. This however carries some risks and is not ordinarily recommended.

When a relative path likefoo/bar.lua is given, they will be turned into the absolute path relative to theserver prefix path determined by the-p PATH command-line option while starting the Nginx server.

When the Lua code cache is turned on (by default), the user code is loaded once at the first request and cachedand the Nginx config must be reloaded each time the Lua source file is modified.The Lua code cache can be temporarily disabled during development by switchinglua_code_cacheoff innginx.conf to avoid repeatedly reloading Nginx.

Nginx variables are supported in the file path for dynamic dispatch just as incontent_by_lua_file.

Back to TOC

syntax:header_filter_by_lua <lua-script-str>

context:http, server, location, location if

phase:output-header-filter

NOTE Use of this directive isdiscouraged following thev0.9.17 release. Use theheader_filter_by_lua_block directive instead.

Similar to theheader_filter_by_lua_block directive, but accepts the Lua source directly in an Nginx string literal (which requiresspecial character escaping).

For instance,

 header_filter_by_lua '     ngx.header["content-length"] = nil ';

This directive was first introduced in thev0.2.1rc20 release.

Back to TOC

syntax:header_filter_by_lua_block { lua-script }

context:http, server, location, location if

phase:output-header-filter

Uses Lua code specified in{ lua-script } to define an output header filter.

Note that the following API functions are currently disabled within this context:

• Output API functions (e.g.,ngx.say andngx.send_headers)
• Control API functions (e.g.,ngx.redirect andngx.exec)
• Subrequest API functions (e.g.,ngx.location.capture andngx.location.capture_multi)
• Cosocket API functions (e.g.,ngx.socket.tcp andngx.req.socket).

Here is an example of overriding a response header (or adding one if absent) in our Lua header filter:

location /{proxy_passhttp://mybackend;     header_filter_by_lua_block{         ngx.header.Foo ="blah"}}

This directive was first introduced in thev0.9.17 release.

Back to TOC

syntax:header_filter_by_lua_file <path-to-lua-script-file>

context:http, server, location, location if

phase:output-header-filter

Equivalent toheader_filter_by_lua_block, except that the file specified by<path-to-lua-script-file> contains the Lua code, or as from thev0.5.0rc32 release, theLuaJIT bytecode to be executed.

When a relative path likefoo/bar.lua is given, they will be turned into the absolute path relative to theserver prefix path determined by the-p PATH command-line option while starting the Nginx server.

This directive was first introduced in thev0.2.1rc20 release.

Back to TOC

syntax:body_filter_by_lua <lua-script-str>

context:http, server, location, location if

phase:output-body-filter

NOTE Use of this directive isdiscouraged following thev0.9.17 release. Use thebody_filter_by_lua_block directive instead.

Similar to thebody_filter_by_lua_block directive, but accepts the Lua source directly in an Nginx string literal (which requiresspecial character escaping).

For instance,

 body_filter_by_lua '     local data, eof = ngx.arg[1], ngx.arg[2] ';

This directive was first introduced in thev0.5.0rc32 release.

Back to TOC

syntax:body_filter_by_lua_block { lua-script-str }

context:http, server, location, location if

phase:output-body-filter

Uses Lua code specified in{ lua-script } to define an output body filter.

The input data chunk is passed viangx.arg[1] (as a Lua string value) and the "eof" flag indicating the end of the response body data stream is passed viangx.arg[2] (as a Lua boolean value).

Behind the scene, the "eof" flag is just thelast_buf (for main requests) orlast_in_chain (for subrequests) flag of the Nginx chain link buffers. (Before thev0.7.14 release, the "eof" flag does not work at all in subrequests.)

The output data stream can be aborted immediately by running the following Lua statement:

returnngx.ERROR

This will truncate the response body and usually result in incomplete and also invalid responses.

The Lua code can pass its own modified version of the input data chunk to the downstream Nginx output body filters by overridingngx.arg[1] with a Lua string or a Lua table of strings. For example, to transform all the lowercase letters in the response body, we can just write:

location /{proxy_passhttp://mybackend;     body_filter_by_lua_block{         ngx.arg[1] = string.upper(ngx.arg[1])}}

When settingnil or an empty Lua string value tongx.arg[1], no data chunk will be passed to the downstream Nginx output filters at all.

Likewise, new "eof" flag can also be specified by setting a boolean value tongx.arg[2]. For example,

location /t{     echo hello world;     echo hiya globe;     body_filter_by_lua_block{         local chunk = ngx.arg[1]if string.match(chunk,"hello") then             ngx.arg[2] = true  -- new eofreturn         end         -- just throw away any remaining chunk data         ngx.arg[1] = nil}}

ThenGET /t will just return the output

hello world

That is, when the body filter sees a chunk containing the word "hello", then it will set the "eof" flag to true immediately, resulting in truncated but still valid responses.

When the Lua code may change the length of the response body, then it is required to always clear out theContent-Length response header (if any) in a header filter to enforce streaming output, as in

location /foo{     # fastcgi_pass/proxy_pass/...     header_filter_by_lua_block{         ngx.header.content_length = nil}     body_filter_by_lua_block{         ngx.arg[1] = string.len(ngx.arg[1]) .."\n"}}

Note that the following API functions are currently disabled within this context due to the limitations in Nginx output filter's current implementation:

• Output API functions (e.g.,ngx.say andngx.send_headers)
• Control API functions (e.g.,ngx.exit andngx.exec)
• Subrequest API functions (e.g.,ngx.location.capture andngx.location.capture_multi)
• Cosocket API functions (e.g.,ngx.socket.tcp andngx.req.socket).

Nginx output filters may be called multiple times for a single request because response body may be delivered in chunks. Thus, the Lua code specified by in this directive may also run multiple times in the lifetime of a single HTTP request.

This directive was first introduced in thev0.9.17 release.

Back to TOC

syntax:body_filter_by_lua_file <path-to-lua-script-file>

context:http, server, location, location if

phase:output-body-filter

Equivalent tobody_filter_by_lua_block, except that the file specified by<path-to-lua-script-file> contains the Lua code, or, as from thev0.5.0rc32 release, theLuaJIT bytecode to be executed.

When a relative path likefoo/bar.lua is given, they will be turned into the absolute path relative to theserver prefix path determined by the-p PATH command-line option while starting the Nginx server.

This directive was first introduced in thev0.5.0rc32 release.

Back to TOC

syntax:log_by_lua <lua-script-str>

context:http, server, location, location if

phase:log

NOTE Use of this directive isdiscouraged following thev0.9.17 release. Use thelog_by_lua_block directive instead.

Similar to thelog_by_lua_block directive, but accepts the Lua source directly in an Nginx string literal (which requiresspecial character escaping).

For instance,

 log_by_lua '     print("I need no extra escaping here, for example:\r\nblah") ';

This directive was first introduced in thev0.5.0rc31 release.

Back to TOC

syntax:log_by_lua_block { lua-script }

context:http, server, location, location if

phase:log

Runs the Lua source code inlined as the{ lua-script } at thelog request processing phase. This does not replace the current access logs, but runs before.

Note that the following API functions are currently disabled within this context:

• Output API functions (e.g.,ngx.say andngx.send_headers)
• Control API functions (e.g.,ngx.exit)
• Subrequest API functions (e.g.,ngx.location.capture andngx.location.capture_multi)
• Cosocket API functions (e.g.,ngx.socket.tcp andngx.req.socket).

Here is an example of gathering average data for$upstream_response_time:

 lua_shared_dict log_dict5M;server{location /{proxy_passhttp://mybackend;         log_by_lua_block{             local log_dict = ngx.shared.log_dict             local upstream_time = tonumber(ngx.var.upstream_response_time)             local sum = log_dict:get("upstream_time-sum") or 0             sum = sum + upstream_time             log_dict:set("upstream_time-sum", sum)             local newval, err = log_dict:incr("upstream_time-nb", 1)if not newval and err =="not found" then                 log_dict:add("upstream_time-nb", 0)                 log_dict:incr("upstream_time-nb", 1)             end}}location = /status{         content_by_lua_block{             local log_dict = ngx.shared.log_dict             local sum = log_dict:get("upstream_time-sum")             local nb = log_dict:get("upstream_time-nb")if nb and sum then                 ngx.say("average upstream response time: ", sum / nb," (", nb," reqs)")             else                 ngx.say("no data yet")             end}}}

This directive was first introduced in thev0.9.17 release.

Back to TOC

syntax:log_by_lua_file <path-to-lua-script-file>

context:http, server, location, location if

phase:log

Equivalent tolog_by_lua_block, except that the file specified by<path-to-lua-script-file> contains the Lua code, or, as from thev0.5.0rc32 release, theLuaJIT bytecode to be executed.

When a relative path likefoo/bar.lua is given, they will be turned into the absolute path relative to theserver prefix path determined by the-p PATH command-line option while starting the Nginx server.

This directive was first introduced in thev0.5.0rc31 release.

Back to TOC

syntax:balancer_by_lua_block { lua-script }

context:upstream

phase:content

This directive runs Lua code as an upstream balancer for any upstream entities definedby theupstream {} configuration block.

For instance,

upstream foo{server127.0.0.1;     balancer_by_lua_block{         --use Lua to do something interesting here         -- as a dynamic balancer}}server{location /{proxy_passhttp://foo;}}

The resulting Lua load balancer can work with any existing Nginx upstream moduleslikengx_proxy andngx_fastcgi.

Also, the Lua load balancer can work with the standard upstream connection pool mechanism,i.e., the standardkeepalive directive.Just ensure that thekeepalive directiveis usedafter thisbalancer_by_lua_block directive in a singleupstream {} configuration block.

The Lua load balancer can totally ignore the list of servers defined in theupstream {} blockand select peer from a completely dynamic server list (even changing per request) via thengx.balancer modulefrom thelua-resty-core library.

The Lua code handler registered by this directive might get called more than once in a singledownstream request when the Nginx upstream mechanism retries the request on conditionsspecified by directives like theproxy_next_upstreamdirective.

This Lua code execution context does not support yielding, so Lua APIs that may yield(like cosockets and "light threads") are disabled in this context. One can usually workaround this limitation by doing such operations in an earlier phase handler (likeaccess_by_lua*) and passing along the result into this contextvia thengx.ctx table.

This directive was first introduced in thev0.10.0 release.

Back to TOC

syntax:balancer_by_lua_file <path-to-lua-script-file>

context:upstream

phase:content

Equivalent tobalancer_by_lua_block, except that the file specified by<path-to-lua-script-file> contains the Lua code, or, as from thev0.5.0rc32 release, theLuaJIT bytecode to be executed.

When a relative path likefoo/bar.lua is given, they will be turned into the absolute path relative to theserver prefix path determined by the-p PATH command-line option while starting the Nginx server.

This directive was first introduced in thev0.10.0 release.

Back to TOC

syntax:balancer_keepalive <total-connections>

context:upstream

phase:loading-config

Thetotal-connections parameter sets the maximum number of idlekeepalive connections to upstream servers that are preserved in the cache ofeach worker process. When this number is exceeded, the least recently usedconnections are closed.

It should be particularly noted that the keepalive directive does not limit thetotal number of connections to upstream servers that an nginx worker processcan open. The connections parameter should be set to a number small enough tolet upstream servers process new incoming connections as well.

This directive was first introduced in thev0.10.21 release.

Back to TOC

syntax:lua_need_request_body <on|off>

default:off

context:http, server, location, location if

phase:depends on usage

Determines whether to force the request body data to be read before running rewrite/access/content_by_lua* or not. The Nginx core does not read the client request body by default and if request body data is required, then this directive should be turnedon or thengx.req.read_body function should be called within the Lua code.

To read the request body data within the$request_body variable,client_body_buffer_size must have the same value asclient_max_body_size. Because when the content length exceedsclient_body_buffer_size but less thanclient_max_body_size, Nginx will buffer the data into a temporary file on the disk, which will lead to empty value in the$request_body variable.

If the current location includesrewrite_by_lua* directives,then the request body will be read just before therewrite_by_lua* code is run (and also at therewrite phase). Similarly, if onlycontent_by_lua is specified,the request body will not be read until the content handler's Lua code isabout to run (i.e., the request body will be read during the content phase).

It is recommended however, to use thengx.req.read_body andngx.req.discard_body functions for finer control over the request body reading process instead.

This also applies toaccess_by_lua*.

Back to TOC

syntax:ssl_client_hello_by_lua_block { lua-script }

context:http, server

phase:right-after-client-hello-message-was-processed

This directive runs user Lua code when Nginx is about to post-process the SSL client hello message for the downstreamSSL (https) connections.

It is particularly useful for dynamically setting the SSL protocols according to the SNI.

It is also useful to do some custom operations according to the per-connection information in the client hello message.

For example, one can parse custom client hello extension and do the corresponding handling in pure Lua.

This Lua handler will always run whether the SSL session is resumed (via SSL session IDs or TLS session tickets) or not.While thessl_certificate_by_lua* Lua handler will only runs when initiating a full SSL handshake.

Thengx.ssl.clienthello Lua modulesprovided by thelua-resty-corelibrary are particularly useful in this context.

Note that this handler runs in extremely early stage of SSL handshake, before the SSL client hello extensions are parsed.So you can not use some Lua API likessl.server_name() which is dependent on the later stage's processing.

Also note that only the directive in default server is valid for several virtual servers with the same IP address and port.

Below is a trivial example using thengx.ssl.clienthello moduleat the same time:

server{listen443ssl;server_name   test.com;ssl_certificate /path/to/cert.crt;ssl_certificate_key /path/to/key.key;     ssl_client_hello_by_lua_block{         local ssl_clt = require"ngx.ssl.clienthello"         local host, err = ssl_clt.get_client_hello_server_name()if host =="test.com" then             ssl_clt.set_protocols({"TLSv1","TLSv1.1"})         elseif host =="test2.com" then             ssl_clt.set_protocols({"TLSv1.2","TLSv1.3"})         elseif not host then             ngx.log(ngx.ERR,"failed to get the SNI name: ", err)             ngx.exit(ngx.ERROR)         else             ngx.log(ngx.ERR,"unknown SNI name: ", host)             ngx.exit(ngx.ERROR)         end}     ...}server{listen443ssl;server_name   test2.com;ssl_certificate /path/to/cert.crt;ssl_certificate_key /path/to/key.key;     ...}

See more information in thengx.ssl.clienthelloLua modules' official documentation.

Uncaught Lua exceptions in the user Lua code immediately abort the current SSL session, so does thengx.exit call with an error code likengx.ERROR.

This Lua code execution contextdoes support yielding, so Lua APIs that may yield(like cosockets, sleeping, and "light threads")are enabled in this context

Note, you need to configure thessl_certificateandssl_certificate_keyto avoid the following error while starting NGINX:

nginx: [emerg] no ssl configured for the server

This directive requires OpenSSL 1.1.1 or greater.

If you are using theofficial pre-builtpackages forOpenResty 1.21.4.1 or later, then everything shouldwork out of the box.

If you are not using the Nginx core shipped withOpenResty 1.21.4.1 or later, you will need to applypatches to the standard Nginx core:

https://openresty.org/en/nginx-ssl-patches.html

Note for HTTP/3 (QUIC) users: When using this directive with HTTP/3 connections, certain yield operations may fail if the QUIC SSL Lua yield patch is not applied to your OpenSSL installation. OpenResty packages include this patch by default, but if you are building lua-nginx-module separately, you may need to apply the patch manually to ensure proper yield/resume functionality for HTTP/3 connections in SSL Lua phases. The patch can be found at:nginx-1.27.1-quic_ssl_lua_yield.patch

This directive was first introduced in thev0.10.21 release.

Back to TOC

syntax:ssl_client_hello_by_lua_file <path-to-lua-script-file>

context:http, server

phase:right-after-client-hello-message-was-processed

Equivalent tossl_client_hello_by_lua_block, except that the file specified by<path-to-lua-script-file> contains the Lua code, or, as from thev0.5.0rc32 release, theLuaJIT bytecode to be executed.

When a relative path likefoo/bar.lua is given, they will be turned into the absolute path relative to theserver prefix path determined by the-p PATH command-line option while starting the Nginx server.

Note for HTTP/3 (QUIC) users: When using this directive with HTTP/3 connections, certain yield operations may fail if the QUIC SSL Lua yield patch is not applied to your OpenSSL installation. OpenResty packages include this patch by default, but if you are building lua-nginx-module separately, you may need to apply the patch manually to ensure proper yield/resume functionality for HTTP/3 connections in SSL Lua phases. The patch can be found at:nginx-1.27.1-quic_ssl_lua_yield.patch

This directive was first introduced in thev0.10.21 release.

Back to TOC

syntax:ssl_certificate_by_lua_block { lua-script }

context:server

phase:right-before-SSL-handshake

This directive runs user Lua code when Nginx is about to start the SSL handshake for the downstreamSSL (https) connections.

It is particularly useful for setting the SSL certificate chain and the corresponding private key on a per-requestbasis. It is also useful to load such handshake configurations nonblockingly from the remote (for example,with thecosocket API). And one can also do per-request OCSP stapling handling in pureLua here as well.

Another typical use case is to do SSL handshake traffic control nonblockingly in this context,with the help of thelua-resty-limit-traffic#readmelibrary, for example.

One can also do interesting things with the SSL handshake requests from the client side, likerejecting old SSL clients using the SSLv3 protocol or even below selectively.

Thengx.sslandngx.ocsp Lua modulesprovided by thelua-resty-corelibrary are particularly useful in this context. You can use the Lua API offered by these two Lua modulesto manipulate the SSL certificate chain and private key for the current SSL connectionbeing initiated.

This Lua handler does not run at all, however, when Nginx/OpenSSL successfully resumesthe SSL session via SSL session IDs or TLS session tickets for the current SSL connection. Inother words, this Lua handler only runs when Nginx has to initiate a full SSL handshake.

Below is a trivial example using thengx.ssl moduleat the same time:

server{listen443ssl;server_name   test.com;     ssl_certificate_by_lua_block{         print("About to initiate a new SSL handshake!")}location /{root html;}}

See more complicated examples in thengx.sslandngx.ocspLua modules' official documentation.

Uncaught Lua exceptions in the user Lua code immediately abort the current SSL session, so does thengx.exit call with an error code likengx.ERROR.

This Lua code execution contextdoes support yielding, so Lua APIs that may yield(like cosockets, sleeping, and "light threads")are enabled in this context.

Note, however, you still need to configure thessl_certificate andssl_certificate_keydirectives even though you will not use this static certificate and private key at all. This isbecause the NGINX core requires their appearance otherwise you are seeing the following errorwhile starting NGINX:

nginx: [emerg] no ssl configured for the server

This directive requires OpenSSL 1.0.2e or greater.

If you are using theofficial pre-builtpackages forOpenResty 1.9.7.2 or later, then everything shouldwork out of the box.

If you are not using the Nginx core shipped withOpenResty 1.9.7.2 or later, you will need to applypatches to the standard Nginx core:

https://openresty.org/en/nginx-ssl-patches.html

Note for HTTP/3 (QUIC) users: When using this directive with HTTP/3 connections, certain yield operations may fail if the QUIC SSL Lua yield patch is not applied to your OpenSSL installation. OpenResty packages include this patch by default, but if you are building lua-nginx-module separately, you may need to apply the patch manually to ensure proper yield/resume functionality for HTTP/3 connections in SSL Lua phases. The patch can be found at:nginx-1.27.1-quic_ssl_lua_yield.patch

This directive was first introduced in thev0.10.0 release.

Back to TOC

syntax:ssl_certificate_by_lua_file <path-to-lua-script-file>

context:server

phase:right-before-SSL-handshake

Equivalent tossl_certificate_by_lua_block, except that the file specified by<path-to-lua-script-file> contains the Lua code, or, as from thev0.5.0rc32 release, theLuaJIT bytecode to be executed.

When a relative path likefoo/bar.lua is given, they will be turned into the absolute path relative to theserver prefix path determined by the-p PATH command-line option while starting the Nginx server.

Note for HTTP/3 (QUIC) users: When using this directive with HTTP/3 connections, certain yield operations may fail if the QUIC SSL Lua yield patch is not applied to your OpenSSL installation. OpenResty packages include this patch by default, but if you are building lua-nginx-module separately, you may need to apply the patch manually to ensure proper yield/resume functionality for HTTP/3 connections in SSL Lua phases. The patch can be found at:nginx-1.27.1-quic_ssl_lua_yield.patch

This directive was first introduced in thev0.10.0 release.

Back to TOC

syntax:ssl_session_fetch_by_lua_block { lua-script }

context:http

phase:right-before-SSL-handshake

This directive runs Lua code to look up and load the SSL session (if any) according to the session IDprovided by the current SSL handshake request for the downstream.

The Lua API for obtaining the current session ID and loading a cached SSL session datais provided in thengx.ssl.sessionLua module shipped with thelua-resty-corelibrary.

Lua APIs that may yield, likengx.sleep andcosockets,are enabled in this context.

This hook, together with thessl_session_store_by_lua* hook,can be used to implement distributed caching mechanisms in pure Lua (basedon thecosocket API, for example). If a cached SSL session is foundand loaded into the current SSL connection context,SSL session resumption can then get immediately initiated and bypass the full SSL handshake process which is very expensive in terms of CPU time.

Please note that TLS session tickets are very different and it is the clients' responsibilityto cache the SSL session state when session tickets are used. SSL session resumptions based onTLS session tickets would happen automatically without going through this hook (nor thessl_session_store_by_lua* hook). This hook is mainlyfor older or less capable SSL clients that can only do SSL sessions by session IDs.

Whenssl_certificate_by_lua* is specified at the same time,this hook usually runs beforessl_certificate_by_lua*.When the SSL session is found and successfully loaded for the current SSL connection,SSL session resumption will happen and thus bypass thessl_certificate_by_lua*hook completely. In this case, Nginx also bypasses thessl_session_store_by_lua*hook, for obvious reasons.

To easily test this hook locally with a modern web browser, you can temporarily put the following linein your https server block to disable the TLS session ticket support:

ssl_session_tickets off;

But do not forget to comment this line out before publishing your site to the world.

If you are using theofficial pre-built packages forOpenResty1.11.2.1 or later, then everything should work out of the box.

If you are not using one of theOpenSSLpackages provided byOpenResty, you will need to apply patches to OpenSSLin order to use this directive:

https://openresty.org/en/openssl-patches.html

Similarly, if you are not using the Nginx core shipped withOpenResty 1.11.2.1 or later, you will need to applypatches to the standard Nginx core:

https://openresty.org/en/nginx-ssl-patches.html

This directive was first introduced in thev0.10.6 release.

Note that this directive can only be used in thehttp context startingwith thev0.10.7 release since SSL session resumption happensbefore server name dispatch.

Back to TOC

syntax:ssl_session_fetch_by_lua_file <path-to-lua-script-file>

context:http

phase:right-before-SSL-handshake

Equivalent tossl_session_fetch_by_lua_block, except that the file specified by<path-to-lua-script-file> contains the Lua code, or rather, theLuaJIT bytecode to be executed.

When a relative path likefoo/bar.lua is given, they will be turned into the absolute path relative to theserver prefix path determined by the-p PATH command-line option while starting the Nginx server.

This directive was first introduced in thev0.10.6 release.

Note that: this directive is only allowed to used inhttp context from thev0.10.7 release(because SSL session resumption happens before server name dispatch).

Back to TOC

syntax:ssl_session_store_by_lua_block { lua-script }

context:http

phase:right-after-SSL-handshake

This directive runs Lua code to fetch and save the SSL session (if any) according to the session IDprovided by the current SSL handshake request for the downstream. The saved or cached SSLsession data can be used for future SSL connections to resume SSL sessions without goingthrough the full SSL handshake process (which is very expensive in terms of CPU time).

Lua APIs that may yield, likengx.sleep andcosockets,aredisabled in this context. You can still, however, use thengx.timer.at APIto create 0-delay timers to save the SSL session data asynchronously to external services (likeredis ormemcached).

The Lua API for obtaining the current session ID and the associated session state datais provided in thengx.ssl.sessionLua module shipped with thelua-resty-corelibrary.

To easily test this hook locally with a modern web browser, you can temporarily put the following linein your https server block to disable the TLS session ticket support:

ssl_session_tickets off;

But do not forget to comment this line out before publishing your site to the world.

This directive was first introduced in thev0.10.6 release.

Note that: this directive is only allowed to used inhttp context from thev0.10.7 release(because SSL session resumption happens before server name dispatch).

Back to TOC

syntax:ssl_session_store_by_lua_file <path-to-lua-script-file>

context:http

phase:right-after-SSL-handshake

Equivalent tossl_session_store_by_lua_block, except that the file specified by<path-to-lua-script-file> contains the Lua code, or rather, theLuaJIT bytecode to be executed.

When a relative path likefoo/bar.lua is given, they will be turned into the absolute path relative to theserver prefix path determined by the-p PATH command-line option while starting the Nginx server.

This directive was first introduced in thev0.10.6 release.

Note that: this directive is only allowed to used inhttp context from thev0.10.7 release(because SSL session resumption happens before server name dispatch).

Back to TOC

syntax:lua_shared_dict <name> <size>

default:no

context:http

phase:depends on usage

Declares a shared memory zone,<name>, to serve as storage for the shm based Lua dictionaryngx.shared.<name>.

Shared memory zones are always shared by all the Nginx worker processes in the current Nginx server instance.

The<size> argument accepts size units such ask andm:

http{     lua_shared_dict dogs10m;     ...}

The hard-coded minimum size is 8KB while the practical minimum size dependson actual user data set (some people start with 12KB).

Seengx.shared.DICT for details.

This directive was first introduced in thev0.3.1rc22 release.

Back to TOC

syntax:lua_socket_connect_timeout <time>

default:lua_socket_connect_timeout 60s

context:http, server, location

This directive controls the default timeout value used in TCP/unix-domain socket object'sconnect method and can be overridden by thesettimeout orsettimeouts methods.

The<time> argument can be an integer, with an optional time unit, likes (second),ms (millisecond),m (minute). The default time unit iss, i.e., "second". The default setting is60s.

This directive was first introduced in thev0.5.0rc1 release.

Back to TOC

syntax:lua_socket_send_timeout <time>

default:lua_socket_send_timeout 60s

context:http, server, location

Controls the default timeout value used in TCP/unix-domain socket object'ssend method and can be overridden by thesettimeout orsettimeouts methods.

The<time> argument can be an integer, with an optional time unit, likes (second),ms (millisecond),m (minute). The default time unit iss, i.e., "second". The default setting is60s.

This directive was first introduced in thev0.5.0rc1 release.

Back to TOC

syntax:lua_socket_send_lowat <size>

default:lua_socket_send_lowat 0

context:http, server, location

Controls thelowat (low water) value for the cosocket send buffer.

Back to TOC

syntax:lua_socket_read_timeout <time>

default:lua_socket_read_timeout 60s

context:http, server, location

phase:depends on usage

This directive controls the default timeout value used in TCP/unix-domain socket object'sreceive method and iterator functions returned by thereceiveuntil method. This setting can be overridden by thesettimeout orsettimeouts methods.

The<time> argument can be an integer, with an optional time unit, likes (second),ms (millisecond),m (minute). The default time unit iss, i.e., "second". The default setting is60s.

This directive was first introduced in thev0.5.0rc1 release.

Back to TOC

syntax:lua_socket_buffer_size <size>

default:lua_socket_buffer_size 4k/8k

context:http, server, location

Specifies the buffer size used by cosocket reading operations.

This buffer does not have to be that big to hold everything at the same time because cosocket supports 100% non-buffered reading and parsing. So even1 byte buffer size should still work everywhere but the performance could be terrible.

This directive was first introduced in thev0.5.0rc1 release.

Back to TOC

syntax:lua_socket_pool_size <size>

default:lua_socket_pool_size 30

context:http, server, location

Specifies the size limit (in terms of connection count) for every cosocket connection pool associated with every remote server (i.e., identified by either the host-port pair or the unix domain socket file path).

Default to 30 connections for every pool.

When the connection pool exceeds the available size limit, the least recently used (idle) connection already in the pool will be closed to make room for the current connection.

Note that the cosocket connection pool is per Nginx worker process rather than per Nginx server instance, so size limit specified here also applies to every single Nginx worker process.

This directive was first introduced in thev0.5.0rc1 release.

Back to TOC

syntax:lua_socket_keepalive_timeout <time>

default:lua_socket_keepalive_timeout 60s

context:http, server, location

This directive controls the default maximal idle time of the connections in the cosocket built-in connection pool. When this timeout reaches, idle connections will be closed and removed from the pool. This setting can be overridden by cosocket objects'setkeepalive method.

The<time> argument can be an integer, with an optional time unit, likes (second),ms (millisecond),m (minute). The default time unit iss, i.e., "second". The default setting is60s.

This directive was first introduced in thev0.5.0rc1 release.

Back to TOC

syntax:lua_socket_log_errors on|off

default:lua_socket_log_errors on

context:http, server, location

This directive can be used to toggle error logging when a failure occurs for the TCP or UDP cosockets. If you are already doing proper error handling and logging in your Lua code, then it is recommended to turn this directive off to prevent data flushing in your Nginx error log files (which is usually rather expensive).

This directive was first introduced in thev0.5.13 release.

Back to TOC

syntax:lua_ssl_ciphers <ciphers>

default:lua_ssl_ciphers DEFAULT

context:http, server, location

Specifies the enabled ciphers for requests to a SSL/TLS server in thetcpsock:sslhandshake method. The ciphers are specified in the format understood by the OpenSSL library.

The full list can be viewed using the “openssl ciphers” command.

This directive was first introduced in thev0.9.11 release.

Back to TOC

syntax:lua_ssl_crl <file>

default:no

context:http, server, location

Specifies a file with revoked certificates (CRL) in the PEM format used to verify the certificate of the SSL/TLS server in thetcpsock:sslhandshake method.

This directive was first introduced in thev0.9.11 release.

Back to TOC

syntax:lua_ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2] [TLSv1.3]

default:lua_ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3

context:http, server, location

Enables the specified protocols for requests to a SSL/TLS server in thetcpsock:sslhandshake method.

The support for theTLSv1.3 parameter requires versionv0.10.12and OpenSSL 1.1.1.From version v0.10.25, the default value change fromSSLV3 TLSv1 TLSv1.1 TLSv1.2 toTLSv1 TLSv1.1 TLSv1.2 TLSv1.3.

This directive was first introduced in thev0.9.11 release.

Back to TOC

syntax:lua_ssl_certificate <file>

default:none

context:http, server, location

Specifies the file path to the SSL/TLS certificate in PEM format used for thetcpsock:sslhandshake method.

This directive allows you to specify the SSL/TLS certificate that will be presented to server during the SSL/TLS handshake process.

This directive was first introduced in thev0.10.26 release.

See alsolua_ssl_certificate_key andlua_ssl_verify_depth.

Back to TOC

syntax:lua_ssl_certificate_key <file>

default:none

context:http, server, location

Specifies the file path to the private key associated with the SSL/TLS certificate used in thetcpsock:sslhandshake method.

This directive allows you to specify the private key file corresponding to the SSL/TLS certificate specified by lua_ssl_certificate. The private key should be in PEM format and must match the certificate.

This directive was first introduced in thev0.10.26 release.

See alsolua_ssl_certificate andlua_ssl_verify_depth.

Back to TOC

syntax:lua_ssl_trusted_certificate <file>

default:none

context:http, server, location

Specifies a file path with trusted CA certificates in the PEM format used to verify the certificate of the SSL/TLS server in thetcpsock:sslhandshake method.

This directive was first introduced in thev0.9.11 release.

See alsolua_ssl_verify_depth.

Back to TOC

syntax:lua_ssl_verify_depth <number>

default:lua_ssl_verify_depth 1

context:http, server, location

Sets the verification depth in the server certificates chain.

This directive was first introduced in thev0.9.11 release.

See alsolua_ssl_certificate,lua_ssl_certificate_key andlua_ssl_trusted_certificate.

Back to TOC

syntax:lua_ssl_key_log <file>

default:none

context:http, server, location

Enables logging of client connection SSL keys in thetcpsock:sslhandshake method and specifies the path to the key log file. Keys are logged in the SSLKEYLOGFILE format compatible with Wireshark.

Back to TOC

syntax:lua_ssl_conf_command <command>

default:no

context:http, server, location

Sets arbitrary OpenSSL configurationcommands.

The directive is supported when using OpenSSL 1.0.2 or higher and nginx 1.19.4 or higher. According to the specify command, higher OpenSSL version may be needed.

Severallua_ssl_conf_command directives can be specified on the same level:

 lua_ssl_conf_command Options PrioritizeChaCha; lua_ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256;

Configuration commands are applied after OpenResty own configuration for SSL, so they can be used to override anything set by OpenResty.

Note though that configuring OpenSSL directly withlua_ssl_conf_command might result in a behaviour OpenResty does not expect, and should be done with care.

This directive was first introduced in thev0.10.21 release.

Back to TOC

syntax:lua_http10_buffering on|off

default:lua_http10_buffering on

context:http, server, location, location-if

Enables or disables automatic response buffering for HTTP 1.0 (or older) requests. This buffering mechanism is mainly used for HTTP 1.0 keep-alive which relies on a properContent-Length response header.

If the Lua code explicitly sets aContent-Length response header before sending the headers (either explicitly viangx.send_headers or implicitly via the firstngx.say orngx.print call), then the HTTP 1.0 response buffering will be disabled even when this directive is turned on.

To output very large response data in a streaming fashion (via thengx.flush call, for example), this directive MUST be turned off to minimize memory usage.

This directive is turnedon by default.

This directive was first introduced in thev0.5.0rc19 release.

Back to TOC

syntax:rewrite_by_lua_no_postpone on|off

default:rewrite_by_lua_no_postpone off

context:http

Controls whether or not to disable postponingrewrite_by_lua* directives to run at the end of therewrite request-processing phase. By default, this directive is turned off and the Lua code is postponed to run at the end of therewrite phase.

This directive was first introduced in thev0.5.0rc29 release.

Back to TOC

syntax:access_by_lua_no_postpone on|off

default:access_by_lua_no_postpone off

context:http

Controls whether or not to disable postponingaccess_by_lua* directives to run at the end of theaccess request-processing phase. By default, this directive is turned off and the Lua code is postponed to run at the end of theaccess phase.

This directive was first introduced in thev0.9.20 release.

Back to TOC

syntax:lua_transform_underscores_in_response_headers on|off

default:lua_transform_underscores_in_response_headers on

context:http, server, location, location-if

Controls whether to transform underscores (_) in the response header names specified in thengx.header.HEADER API to hyphens (-).

This directive was first introduced in thev0.5.0rc32 release.

Back to TOC

syntax:lua_check_client_abort on|off

default:lua_check_client_abort off

context:http, server, location, location-if

This directive controls whether to check for premature client connection abortion.

When this directive is on, the ngx_lua module will monitor the premature connection close event on the downstream connections and when there is such an event, it will call the user Lua function callback (registered byngx.on_abort) or just stop and clean up all the Lua "light threads" running in the current request's request handler when there is no user callback function registered.

According to the current implementation, however, if the client closes the connection before the Lua code finishes reading the request body data viangx.req.socket, then ngx_lua will neither stop all the running "light threads" nor call the user callback (ifngx.on_abort has been called). Instead, the reading operation onngx.req.socket will just return the error message "client aborted" as the second return value (the first return value is surelynil).

When TCP keepalive is disabled, it is relying on the client side to close the socket gracefully (by sending aFIN packet or something like that). For (soft) real-time web applications, it is highly recommended to configure theTCP keepalive support in your system's TCP stack implementation in order to detect "half-open" TCP connections in time.

For example, on Linux, you can configure the standardlisten directive in yournginx.conf file like this:

listen80 so_keepalive=2s:2s:8;

On FreeBSD, you can only tune the system-wide configuration for TCP keepalive, for example:

# sysctl net.inet.tcp.keepintvl=2000# sysctl net.inet.tcp.keepidle=2000

This directive was first introduced in thev0.7.4 release.

See alsongx.on_abort.

Back to TOC

syntax:lua_max_pending_timers <count>

default:lua_max_pending_timers 1024

context:http

Controls the maximum number of pending timers allowed.

Pending timers are those timers that have not expired yet.

When exceeding this limit, thengx.timer.at call will immediately returnnil and the error string "too many pending timers".

This directive was first introduced in thev0.8.0 release.

Back to TOC

syntax:lua_max_running_timers <count>

default:lua_max_running_timers 256

context:http

Controls the maximum number of "running timers" allowed.

Running timers are those timers whose user callback functions are still running orlightthreads spawned in callback functions are still running.

When exceeding this limit, Nginx will stop running the callbacks of newly expired timers and log an error message "N lua_max_running_timers are not enough" where "N" is the current value of this directive.

This directive was first introduced in thev0.8.0 release.

Back to TOC

syntax:lua_sa_restart on|off

default:lua_sa_restart on

context:http

When enabled, this module will set theSA_RESTART flag on Nginx workers signal dispositions.

This allows Lua I/O primitives to not be interrupted by Nginx's handling of various signals.

This directive was first introduced in thev0.10.14 release.

Back to TOC

syntax:lua_worker_thread_vm_pool_size <size>

default:lua_worker_thread_vm_pool_size 10

context:http

Specifies the size limit of the Lua VM pool (default 100) that will be used in thengx.run_worker_thread API.

Also, it is not allowed to create Lua VMs that exceeds the pool size limit.

The Lua VM in the VM pool is used to execute Lua code in separate thread.

The pool is global at Nginx worker level. And it is used to reuse Lua VMs between requests.

Warning: Each worker thread uses a separate Lua VM and caches the Lua VM for reuse in subsequent operations. Configuring too many worker threads can result in consuming a lot of memory.

Back to TOC

• Introduction
• ngx.arg
• ngx.var.VARIABLE
• Core constants
• HTTP method constants
• HTTP status constants
• Nginx log level constants
• print
• ngx.ctx
• ngx.location.capture
• ngx.location.capture_multi
• ngx.status
• ngx.header.HEADER
• ngx.resp.get_headers
• ngx.req.is_internal
• ngx.req.start_time
• ngx.req.http_version
• ngx.req.raw_header
• ngx.req.get_method
• ngx.req.set_method
• ngx.req.set_uri
• ngx.req.set_uri_args
• ngx.req.get_uri_args
• ngx.req.get_post_args
• ngx.req.get_headers
• ngx.req.set_header
• ngx.req.clear_header
• ngx.req.read_body
• ngx.req.discard_body
• ngx.req.get_body_data
• ngx.req.get_body_file
• ngx.req.set_body_data
• ngx.req.set_body_file
• ngx.req.init_body
• ngx.req.append_body
• ngx.req.finish_body
• ngx.req.socket
• ngx.exec
• ngx.redirect
• ngx.send_headers
• ngx.headers_sent
• ngx.print
• ngx.say
• ngx.log
• ngx.flush
• ngx.exit
• ngx.eof
• ngx.sleep
• ngx.escape_uri
• ngx.unescape_uri
• ngx.encode_args
• ngx.decode_args
• ngx.encode_base64
• ngx.decode_base64
• ngx.decode_base64mime
• ngx.crc32_short
• ngx.crc32_long
• ngx.hmac_sha1
• ngx.md5
• ngx.md5_bin
• ngx.sha1_bin
• ngx.quote_sql_str
• ngx.today
• ngx.time
• ngx.now
• ngx.update_time
• ngx.localtime
• ngx.utctime
• ngx.cookie_time
• ngx.http_time
• ngx.parse_http_time
• ngx.is_subrequest
• ngx.re.match
• ngx.re.find
• ngx.re.gmatch
• ngx.re.sub
• ngx.re.gsub
• ngx.shared.DICT
• ngx.shared.DICT.get
• ngx.shared.DICT.get_stale
• ngx.shared.DICT.set
• ngx.shared.DICT.safe_set
• ngx.shared.DICT.add
• ngx.shared.DICT.safe_add
• ngx.shared.DICT.replace
• ngx.shared.DICT.delete
• ngx.shared.DICT.incr
• ngx.shared.DICT.lpush
• ngx.shared.DICT.rpush
• ngx.shared.DICT.lpop
• ngx.shared.DICT.rpop
• ngx.shared.DICT.llen
• ngx.shared.DICT.ttl
• ngx.shared.DICT.expire
• ngx.shared.DICT.flush_all
• ngx.shared.DICT.flush_expired
• ngx.shared.DICT.get_keys
• ngx.shared.DICT.capacity
• ngx.shared.DICT.free_space
• ngx.socket.udp
• udpsock:bind
• udpsock:setpeername
• udpsock:send
• udpsock:receive
• udpsock:close
• udpsock:settimeout
• ngx.socket.stream
• ngx.socket.tcp
• tcpsock:bind
• tcpsock:connect
• tcpsock:getfd
• tcpsock:setclientcert
• tcpsock:sslhandshake
• tcpsock:send
• tcpsock:receive
• tcpsock:receiveany
• tcpsock:receiveuntil
• tcpsock:close
• tcpsock:settimeout
• tcpsock:settimeouts
• tcpsock:setoption
• tcpsock:setkeepalive
• tcpsock:getreusedtimes
• ngx.socket.connect
• ngx.get_phase
• ngx.thread.spawn
• ngx.thread.wait
• ngx.thread.kill
• ngx.on_abort
• ngx.timer.at
• ngx.timer.every
• ngx.timer.running_count
• ngx.timer.pending_count
• ngx.config.subsystem
• ngx.config.debug
• ngx.config.prefix
• ngx.config.nginx_version
• ngx.config.nginx_configure
• ngx.config.ngx_lua_version
• ngx.worker.exiting
• ngx.worker.pid
• ngx.worker.pids
• ngx.worker.count
• ngx.worker.id
• ngx.semaphore
• ngx.balancer
• ngx.ssl
• ngx.ocsp
• ndk.set_var.DIRECTIVE
• coroutine.create
• coroutine.resume
• coroutine.yield
• coroutine.wrap
• coroutine.running
• coroutine.status
• ngx.run_worker_thread

Back to TOC

The various*_by_lua,*_by_lua_block and*_by_lua_file configuration directives serve as gateways to the Lua API within thenginx.conf file. The Nginx Lua API described below can only be called within the user Lua code run in the context of these configuration directives.

The API is exposed to Lua in the form of two standard packagesngx andndk. These packages are in the default global scope within ngx_lua and are always available within ngx_lua directives.

The packages can be introduced into external Lua modules like this:

localsay=ngx.saylocal_M= {}function_M.foo(a)say(a)endreturn_M

Use of thepackage.seeall flag is strongly discouraged due to its various bad side-effects.

It is also possible to directly require the packages in external Lua modules:

localngx=require"ngx"localndk=require"ndk"

The ability to require these packages was introduced in thev0.2.1rc19 release.

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. Disk operations with relatively small amount of data can be done using the standard Luaio library but huge file reading and writing should be avoided wherever possible as they may block the Nginx process significantly. Delegating all network and disk I/O operations to Nginx's subrequests (via thengx.location.capture method and similar) is strongly recommended for maximum performance.

Back to TOC

syntax:val = ngx.arg[index]

context:set_by_lua*, body_filter_by_lua*

When this is used in the context of theset_by_lua* directives, this table is read-only and holds the input arguments to the config directives:

value=ngx.arg[n]

Here is an example

location /foo{set$a32;set$b56;     set_by_lua$sum'return tonumber(ngx.arg[1]) + tonumber(ngx.arg[2])'$a$b;     echo$sum;}

that writes out88, the sum of32 and56.

When this table is used in the context ofbody_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.

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. When settingnil or an empty Lua string value tongx.arg[1], no data chunk will be passed to the downstream Nginx output filters at all.

Back to TOC

syntax:ngx.var.VAR_NAME

context:set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, log_by_lua*, balancer_by_lua*

Read and write Nginx variable values.

 value = ngx.var.some_nginx_variable_name ngx.var.some_nginx_variable_name = value

Note that only already defined Nginx variables can be written to.For example:

location /foo{set$my_var''; # this line is required to create$my_var at config time     content_by_lua_block{         ngx.var.my_var =123         ...}}

That is, Nginx variables cannot be created on-the-fly. Here is a list of pre-definedNginx variables.

Some special Nginx variables like$args and$limit_rate can be assigned a value,many others are not, like$query_string,$arg_PARAMETER, and$http_NAME.

Nginx regex group capturing variables$1,$2,$3, and etc, can be read by thisinterface as well, by writingngx.var[1],ngx.var[2],ngx.var[3], and etc.

Settingngx.var.Foo to anil value will unset the$Foo Nginx variable.

ngx.var.args=nil

CAUTION When reading from an Nginx variable, Nginx will allocate memory in the per-request memory pool which is freed only at request termination. So when you need to read from an Nginx variable repeatedly in your Lua code, cache the Nginx variable value to your own Lua variable, for example,

localval=ngx.var.some_var--- use the val repeatedly later

to prevent (temporary) memory leaking within the current request's lifetime. Another way of caching the result is to use thengx.ctx table.

Undefined Nginx variables are evaluated tonil while uninitialized (but defined) Nginx variables are evaluated to an empty Lua string.

This API requires a relatively expensive metamethod call and it is recommended to avoid using it on hot code paths.

Back to TOC

context:init_by_lua*, set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, *log_by_lua*, ngx.timer.*, balancer_by_lua*, ssl_certificate_by_lua*, ssl_session_fetch_by_lua*, ssl_session_store_by_lua*, ssl_client_hello_by_lua*

ngx.OK (0)ngx.ERROR (-1)ngx.AGAIN (-2)ngx.DONE (-4)ngx.DECLINED (-5)

Note that only three of these constants are utilized by theNginx API for Lua (i.e.,ngx.exit acceptsngx.OK,ngx.ERROR, andngx.DECLINED as input).

ngx.null

Thengx.null constant is aNULL light userdata usually used to represent nil values in Lua tables etc and is similar to thelua-cjson library'scjson.null constant. This constant was first introduced in thev0.5.0rc5 release.

Thengx.DECLINED constant was first introduced in thev0.5.0rc19 release.

Back to TOC

context:init_by_lua*, set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, log_by_lua*, ngx.timer.*, balancer_by_lua*, ssl_certificate_by_lua*, ssl_session_fetch_by_lua*, ssl_session_store_by_lua*, ssl_client_hello_by_lua*

  ngx.HTTP_GET  ngx.HTTP_HEAD  ngx.HTTP_PUT  ngx.HTTP_POST  ngx.HTTP_DELETE  ngx.HTTP_OPTIONS   (added in the v0.5.0rc24 release)  ngx.HTTP_MKCOL     (added in the v0.8.2 release)  ngx.HTTP_COPY      (added in the v0.8.2 release)  ngx.HTTP_MOVE      (added in the v0.8.2 release)  ngx.HTTP_PROPFIND  (added in the v0.8.2 release)  ngx.HTTP_PROPPATCH (added in the v0.8.2 release)  ngx.HTTP_LOCK      (added in the v0.8.2 release)  ngx.HTTP_UNLOCK    (added in the v0.8.2 release)  ngx.HTTP_PATCH     (added in the v0.8.2 release)  ngx.HTTP_TRACE     (added in the v0.8.2 release)

These constants are usually used inngx.location.capture andngx.location.capture_multi method calls.

Back to TOC

context:init_by_lua*, set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, log_by_lua*, ngx.timer.*, balancer_by_lua*, ssl_certificate_by_lua*, ssl_session_fetch_by_lua*, ssl_session_store_by_lua*, ssl_client_hello_by_lua*

   value = ngx.HTTP_CONTINUE(100)(first added in the v0.9.20 release)   value = ngx.HTTP_SWITCHING_PROTOCOLS(101)(first added in the v0.9.20 release)   value = ngx.HTTP_OK(200)   value = ngx.HTTP_CREATED(201)   value = ngx.HTTP_ACCEPTED(202)(first added in the v0.9.20 release)   value = ngx.HTTP_NO_CONTENT(204)(first added in the v0.9.20 release)   value = ngx.HTTP_PARTIAL_CONTENT(206)(first added in the v0.9.20 release)   value = ngx.HTTP_SPECIAL_RESPONSE(300)   value = ngx.HTTP_MOVED_PERMANENTLY(301)   value = ngx.HTTP_MOVED_TEMPORARILY(302)   value = ngx.HTTP_SEE_OTHER(303)   value = ngx.HTTP_NOT_MODIFIED(304)   value = ngx.HTTP_TEMPORARY_REDIRECT(307)(first added in the v0.9.20 release)   value = ngx.HTTP_PERMANENT_REDIRECT(308)   value = ngx.HTTP_BAD_REQUEST(400)   value = ngx.HTTP_UNAUTHORIZED(401)   value = ngx.HTTP_PAYMENT_REQUIRED(402)(first added in the v0.9.20 release)   value = ngx.HTTP_FORBIDDEN(403)   value = ngx.HTTP_NOT_FOUND(404)   value = ngx.HTTP_NOT_ALLOWED(405)   value = ngx.HTTP_NOT_ACCEPTABLE(406)(first added in the v0.9.20 release)   value = ngx.HTTP_REQUEST_TIMEOUT(408)(first added in the v0.9.20 release)   value = ngx.HTTP_CONFLICT(409)(first added in the v0.9.20 release)   value = ngx.HTTP_GONE(410)   value = ngx.HTTP_UPGRADE_REQUIRED(426)(first added in the v0.9.20 release)   value = ngx.HTTP_TOO_MANY_REQUESTS(429)(first added in the v0.9.20 release)   value = ngx.HTTP_CLOSE(444)(first added in the v0.9.20 release)   value = ngx.HTTP_ILLEGAL(451)(first added in the v0.9.20 release)   value = ngx.HTTP_INTERNAL_SERVER_ERROR(500)   value = ngx.HTTP_NOT_IMPLEMENTED(501)   value = ngx.HTTP_METHOD_NOT_IMPLEMENTED(501)(keptfor compatibility)   value = ngx.HTTP_BAD_GATEWAY(502)(first added in the v0.9.20 release)   value = ngx.HTTP_SERVICE_UNAVAILABLE(503)   value = ngx.HTTP_GATEWAY_TIMEOUT(504)(first added in the v0.3.1rc38 release)   value = ngx.HTTP_VERSION_NOT_SUPPORTED(505)(first added in the v0.9.20 release)   value = ngx.HTTP_INSUFFICIENT_STORAGE(507)(first added in the v0.9.20 release)

Back to TOC

context:init_by_lua*, init_worker_by_lua*, set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, log_by_lua*, ngx.timer.*, balancer_by_lua*, ssl_certificate_by_lua*, ssl_session_fetch_by_lua*, ssl_session_store_by_lua*, exit_worker_by_lua*, ssl_client_hello_by_lua*

ngx.STDERRngx.EMERGngx.ALERTngx.CRITngx.ERRngx.WARNngx.NOTICEngx.INFOngx.DEBUG

These constants are usually used by thengx.log method.

Back to TOC

syntax:print(...)

context:init_by_lua*, init_worker_by_lua*, set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, log_by_lua*, ngx.timer.*, balancer_by_lua*, ssl_certificate_by_lua*, ssl_session_fetch_by_lua*, ssl_session_store_by_lua*, exit_worker_by_lua*, ssl_client_hello_by_lua*

Writes argument values into the Nginxerror.log file with thengx.NOTICE log level.

It is equivalent to

ngx.log(ngx.NOTICE,...)

Luanil arguments are accepted and result in literal"nil" strings while Lua booleans result in literal"true" or"false" strings. And thengx.null constant will yield the"null" string output.

There is a hard coded2048 byte limitation on error message lengths in the Nginx core. This limit includes trailing newlines and leading time stamps. If the message size exceeds this limit, Nginx will truncate the message text accordingly. This limit can be manually modified by editing theNGX_MAX_ERROR_STR macro definition in thesrc/core/ngx_log.h file in the Nginx source tree.

Back to TOC

context:init_worker_by_lua*, set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, log_by_lua*, ngx.timer.*, balancer_by_lua*, exit_worker_by_lua*

This table can be used to store per-request Lua context data and has a life time identical to the current request (as with the Nginx variables).

Consider the following example,

location /test{     rewrite_by_lua_block{         ngx.ctx.foo =76}     access_by_lua_block{         ngx.ctx.foo = ngx.ctx.foo + 3}     content_by_lua_block{         ngx.say(ngx.ctx.foo)}}

ThenGET /test will yield the output

 79

That is, thengx.ctx.foo entry persists across the rewrite, access, and content phases of a request.

Every request, including subrequests, has its own copy of the table. For example:

location /sub{     content_by_lua_block{         ngx.say("sub pre: ", ngx.ctx.blah)         ngx.ctx.blah =32         ngx.say("sub post: ", ngx.ctx.blah)}}location /main{     content_by_lua_block{         ngx.ctx.blah =73         ngx.say("main pre: ", ngx.ctx.blah)         local res = ngx.location.capture("/sub")         ngx.print(res.body)         ngx.say("main post: ", ngx.ctx.blah)}}

ThenGET /main will give the output

 main pre: 73 sub pre: nil sub post: 32 main post: 73

Here, modification of thengx.ctx.blah entry in the subrequest does not affect the one in the parent request. This is because they have two separate versions ofngx.ctx.blah.

Internal redirects (triggered by nginx configuration directives likeerror_page,try_files,index, etc.) will destroy the original requestngx.ctx data (if any) and the new request will have an emptyngx.ctx table. For instance,

location /new{     content_by_lua_block{         ngx.say(ngx.ctx.foo)}}location /orig{     content_by_lua_block{         ngx.ctx.foo ="hello"         ngx.exec("/new")}}

ThenGET /orig will give

 nil

rather than the original"hello" value.

Because HTTP request is created after SSL handshake, thengx.ctx createdinssl_certificate_by_lua*,ssl_session_store_by_lua*,ssl_session_fetch_by_lua* andssl_client_hello_by_lua*is not available in the following phases likerewrite_by_lua*.

Sincev0.10.18, thengx.ctx created during a SSL handshakewill be inherited by the requests which share the same TCP connection established by the handshake.Note that overwrite values inngx.ctx in the http request phases (likerewrite_by_lua*) will only take affect in the current http request.

Arbitrary data values, including Lua closures and nested tables, can be inserted into this "magic" table. It also allows the registration of custom meta methods.

Overridingngx.ctx with a new Lua table is also supported, for example,

ngx.ctx= {foo=32,bar=54 }

When being used in the context ofinit_worker_by_lua*, this table just has the same lifetime of the current Lua handler.

Thengx.ctx lookup requires relatively expensive metamethod calls and it is much slower than explicitly passing per-request data along by your own function arguments. So do not abuse this API for saving your own function arguments because it usually has quite some performance impact.

Because of the metamethod magic, never "local" thengx.ctx table outside your Lua function scope on the Lua module level due toworker-level data sharing. For example, the following is bad:

-- mymodule.lualocal_M= {}-- the following line is bad since ngx.ctx is a per-request-- data while this <code>ctx</code> variable is on the Lua module level-- and thus is per-nginx-worker.localctx=ngx.ctxfunction_M.main()ctx.foo="bar"endreturn_M

Use the following instead:

-- mymodule.lualocal_M= {}function_M.main(ctx)ctx.foo="bar"endreturn_M

That is, let the caller pass thectx table explicitly via a function argument.

Back to TOC

syntax:res = ngx.location.capture(uri, options?)

context:rewrite_by_lua*, access_by_lua*, content_by_lua*

Issues a synchronous but still non-blockingNginx Subrequest usinguri.

Nginx's subrequests provide a powerful way to make non-blocking internal requests to other locations configured with disk file directory orany other Nginx C modules likengx_proxy,ngx_fastcgi,ngx_memc,ngx_postgres,ngx_drizzle, and even ngx_lua itself and etc etc etc.

Also note that subrequests just mimic the HTTP interface but there isno extra HTTP/TCP trafficnor IPC involved. Everything works internally, efficiently, on the C level.

Subrequests are completely different from HTTP 301/302 redirection (viangx.redirect) and internal redirection (viangx.exec).

You should always read the request body (by either callingngx.req.read_body or configuringlua_need_request_body on) before initiating a subrequest.

This API function (as well asngx.location.capture_multi) always buffers the whole response body of the subrequest in memory. Thus, you should usecosocketsand streaming processing instead if you have to handle large subrequest responses.

Here is a basic example:

res=ngx.location.capture(uri)

Returns a Lua table with 4 slots:res.status,res.header,res.body, andres.truncated.

res.status holds the response status code for the subrequest response.

res.header holds all the response headers of thesubrequest and it is a normal Lua table. For multi-value response headers,the value is a Lua (array) table that holds all the values in the order thatthey appear. For instance, if the subrequest response headers contain the followinglines:

 Set-Cookie: a=3 Set-Cookie: foo=bar Set-Cookie: baz=blah

Thenres.header["Set-Cookie"] will be evaluated to the table value{"a=3", "foo=bar", "baz=blah"}.

res.body holds the subrequest's response body data, which might be truncated. You always need to check theres.truncated boolean flag to see ifres.body contains truncated data. The data truncation here can only be caused by those unrecoverable errors in your subrequests like the cases that the remote end aborts the connection prematurely in the middle of the response body data stream or a read timeout happens when your subrequest is receiving the response body data from the remote.

URI query strings can be concatenated to URI itself, for instance,

res=ngx.location.capture('/foo/bar?a=3&b=4')

Named locations like@foo are not allowed due to a limitation inthe Nginx core. Use normal locations combined with theinternal directive toprepare internal-only locations.

An optional option table can be fed as the secondargument, which supports the options:

• methodspecify the subrequest's request method, which only accepts constants likengx.HTTP_POST.
• bodyspecify the subrequest's request body (string value only).
• argsspecify the subrequest's URI query arguments (both string value and Lua tables are accepted)
• headersspecify the subrequest's request headers (Lua table only). this headers will override the original headers of the subrequest.
• ctxspecify a Lua table to be thengx.ctx table for the subrequest. It can be the current request'sngx.ctx table, which effectively makes the parent and its subrequest to share exactly the same context table. This option was first introduced in thev0.3.1rc25 release.
• varstake a Lua table which holds the values to set the specified Nginx variables in the subrequest as this option's value. This option was first introduced in thev0.3.1rc31 release.
• copy_all_varsspecify whether to copy over all the Nginx variable values of the current request to the subrequest in question. modifications of the Nginx variables in the subrequest will not affect the current (parent) request. This option was first introduced in thev0.3.1rc31 release.
• share_all_varsspecify whether to share all the Nginx variables of the subrequest with the current (parent) request. modifications of the Nginx variables in the subrequest will affect the current (parent) request. Enabling this option may lead to hard-to-debug issues due to bad side-effects and is considered bad and harmful. Only enable this option when you completely know what you are doing.
• always_forward_bodywhen set to true, the current (parent) request's request body will always be forwarded to the subrequest being created if thebody option is not specified. The request body read by eitherngx.req.read_body() orlua_need_request_body on will be directly forwarded to the subrequest without copying the whole request body data when creating the subrequest (no matter the request body data is buffered in memory buffers or temporary files). By default, this option isfalse and when thebody option is not specified, the request body of the current (parent) request is only forwarded when the subrequest takes thePUT orPOST request method.

Issuing a POST subrequest, for example, can be done as follows

res=ngx.location.capture('/foo/bar',     {method=ngx.HTTP_POST,body='hello, world'} )

See HTTP method constants methods other than POST.Themethod option isngx.HTTP_GET by default.

Theargs option can specify extra URI arguments, for instance,

ngx.location.capture('/foo?a=1',     {args= {b=3,c=':'} } )

is equivalent to

ngx.location.capture('/foo?a=1&b=3&c=%3a')

that is, this method will escape argument keys and values according to URI rules andconcatenate them together into a complete query string. The format for the Lua table passed as theargs argument is identical to the format used in thengx.encode_args method.

Theargs option can also take plain query strings:

ngx.location.capture('/foo?a=1',     {args='b=3&c=%3a'} )

This is functionally identical to the previous examples.

Theshare_all_vars option controls whether to share Nginx variables among the current request and its subrequests.If this option is set totrue, then the current request and associated subrequests will share the same Nginx variable scope. Hence, changes to Nginx variables made by a subrequest will affect the current request.

Care should be taken in using this option as variable scope sharing can have unexpected side effects. Theargs,vars, orcopy_all_vars options are generally preferable instead.

This option is set tofalse by default

location /other{set$dog"$dog world";     echo"$uri dog: $dog";}location /lua{set$dog'hello';     content_by_lua_block{         res = ngx.location.capture("/other",{ share_all_vars = true})         ngx.print(res.body)         ngx.say(ngx.var.uri,": ", ngx.var.dog)}}

Accessing location/lua gives

/other dog: hello world/lua: hello world

Thecopy_all_vars option provides a copy of the parent request's Nginx variables to subrequests when such subrequests are issued. Changes made to these variables by such subrequests will not affect the parent request or any other subrequests sharing the parent request's variables.

location /other{set$dog"$dog world";     echo"$uri dog: $dog";}location /lua{set$dog'hello';     content_by_lua_block{         res = ngx.location.capture("/other",{ copy_all_vars = true})         ngx.print(res.body)         ngx.say(ngx.var.uri,": ", ngx.var.dog)}}

RequestGET /lua will give the output

/other dog: hello world/lua: hello

Note that if bothshare_all_vars andcopy_all_vars are set to true, thenshare_all_vars takes precedence.

In addition to the two settings above, it is possible to specifyvalues for variables in the subrequest using thevars option. Thesevariables are set after the sharing or copying of variables has beenevaluated, and provides a more efficient method of passing specificvalues to a subrequest over encoding them as URL arguments andunescaping them in the Nginx config file.

location /other{     content_by_lua_block{         ngx.say("dog = ", ngx.var.dog)         ngx.say("cat = ", ngx.var.cat)}}location /lua{set$dog'';set$cat'';     content_by_lua_block{         res = ngx.location.capture("/other",{ vars ={ dog ="hello", cat =32}})         ngx.print(res.body)}}

Accessing/lua will yield the output

dog = hellocat = 32

Theheaders option can be used to specify the request headers for the subrequest. The value of this option should be a Lua table where the keys are the header names and the values are the header values. For example,

location/foo {content_by_lua_block {ngx.print(ngx.var.http_x_test)    }}location/lua {content_by_lua_block {localres=ngx.location.capture("/foo", {headers= {                ["X-Test"]="aa",            }        })ngx.print(res.body)    }}

Accessing/lua will yield the output

aa

Thectx option can be used to specify a custom Lua table to serve as thengx.ctx table for the subrequest.

location /sub{     content_by_lua_block{         ngx.ctx.foo ="bar";}}location /lua{     content_by_lua_block{         local ctx ={}         res = ngx.location.capture("/sub",{ ctx = ctx})         ngx.say(ctx.foo)         ngx.say(ngx.ctx.foo)}}

Then requestGET /lua gives

barnil

It is also possible to use thisctx option to share the samengx.ctx table between the current (parent) request and the subrequest:

location /sub{     content_by_lua_block{         ngx.ctx.foo ="bar"}}location /lua{     content_by_lua_block{         res = ngx.location.capture("/sub",{ ctx = ngx.ctx})         ngx.say(ngx.ctx.foo)}}

RequestGET /lua yields the output

bar

Note that subrequests issued byngx.location.capture inherit all therequest headers of the current request by default and that this may have unexpected side effects on thesubrequest responses. For example, when using the standardngx_proxy module to servesubrequests, an "Accept-Encoding: gzip" header in the main request may resultin gzipped responses that cannot be handled properly in Lua code. Original request headers should be ignored by settingproxy_pass_request_headers tooff in subrequest locations.

When thebody option is not specified and thealways_forward_body option is false (the default value), thePOST andPUT subrequests will inherit the request bodies of the parent request (if any).

There is a hard-coded upper limit on the number of subrequests possible for every main request. In older versions of Nginx, the limit was50 concurrent subrequests and in more recent versions, Nginx1.9.5 onwards, the same limit is changed to limit the depth of recursive subrequests. When this limit is exceeded, the following error message is added to theerror.log file:

[error] 13983#0: *1 subrequests cycle while processing "/uri"

The limit can be manually modified if required by editing the definition of theNGX_HTTP_MAX_SUBREQUESTS macro in thenginx/src/http/ngx_http_request.h file in the Nginx source tree.

Please also refer to restrictions on capturing locations configured bysubrequest directives of other modules.

Back to TOC

syntax:res1, res2, ... = ngx.location.capture_multi({ {uri, options?}, {uri, options?}, ... })

context:rewrite_by_lua*, access_by_lua*, content_by_lua*

Just likengx.location.capture, but supports multiple subrequests running in parallel.

This function issues several parallel subrequests specified by the input table and returns their results in the same order. For example,

res1,res2,res3=ngx.location.capture_multi{     {"/foo", {args="a=3&b=4"} },     {"/bar"},     {"/baz", {method=ngx.HTTP_POST,body="hello"} }, }ifres1.status==ngx.HTTP_OKthen...endifres2.body=="BLAH"then...end

This function will not return until all the subrequests terminate.The total latency is the longest latency of the individual subrequests rather than the sum.

Lua tables can be used for both requests and responses when the number of subrequests to be issued is not known in advance:

-- construct the requests tablelocalreqs= {}table.insert(reqs, {"/mysql"})table.insert(reqs, {"/postgres"})table.insert(reqs, {"/redis"})table.insert(reqs, {"/memcached"})-- issue all the requests at once and wait until they all returnlocalresps= {ngx.location.capture_multi(reqs) }-- loop over the responses tablefori,respinipairs(resps)do-- process the response table "resp"end

Thengx.location.capture function is just a special formof this function. Logically speaking, thengx.location.capture can be implemented like this

ngx.location.capture=function (uri,args)returnngx.location.capture_multi({ {uri,args} })end

Please also refer to restrictions on capturing locations configured bysubrequest directives of other modules.

Back to TOC

context:set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, log_by_lua*

Read and write the current request's response status. This should be calledbefore sending out the response headers.

ngx.status=ngx.HTTP_CREATEDstatus=ngx.status

Settingngx.status after the response header is sent out has no effect but leaving an error message in your Nginx's error log file:

attempt to set ngx.status after sending out response headers

Back to TOC

syntax:ngx.header.HEADER = VALUE

syntax:value = ngx.header.HEADER

context:rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, log_by_lua*

Set, add to, or clear the current request'sHEADER response header that is to be sent.

Underscores (_) in the header names will be replaced by hyphens (-) by default. This transformation can be turned off via thelua_transform_underscores_in_response_headers directive.

The header names are matched case-insensitively.

-- equivalent to ngx.header["Content-Type"] = 'text/plain'ngx.header.content_type='text/plain'ngx.header["X-My-Header"]='blah blah'

Multi-value headers can be set this way:

ngx.header['Set-Cookie']= {'a=32; path=/','b=4; path=/'}

will yield

 Set-Cookie: a=32; path=/ Set-Cookie: b=4; path=/

in the response headers.

Only Lua tables are accepted (Only the last element in the table will take effect for standard headers such asContent-Type that only accept a single value).

ngx.header.content_type= {'a','b'}

is equivalent to

ngx.header.content_type='b'

Setting a slot tonil effectively removes it from the response headers:

ngx.header["X-My-Header"]=nil

The same applies to assigning an empty table:

ngx.header["X-My-Header"]= {}

Settingngx.header.HEADER after sending out response headers (either explicitly withngx.send_headers or implicitly withngx.print and similar) will log an error message.

Readingngx.header.HEADER will return the value of the response header namedHEADER.

Underscores (_) in the header names will also be replaced by dashes (-) and the header names will be matched case-insensitively. If the response header is not present at all,nil will be returned.

This is particularly useful in the context ofheader_filter_by_lua*, for example,

location /test{set$footer'';proxy_passhttp://some-backend;     header_filter_by_lua_block{if ngx.header["X-My-Header"] =="blah" then             ngx.var.footer ="some value"         end}     echo_after_body$footer;}

For multi-value headers, all of the values of header will be collected in order and returned as a Lua table. For example, response headers

Foo: barFoo: baz

will result in

 {"bar","baz"}

to be returned when readingngx.header.Foo.

Note thatngx.header is not a normal Lua table and as such, it is not possible to iterate through it using the Luaipairs function.

Note: this function throws a Lua error ifHEADER orVALUE contain unsafe characters (control characters).

For readingrequest headers, use thengx.req.get_headers function instead.

Back to TOC

syntax:headers, err = ngx.resp.get_headers(max_headers?, raw?)

context:set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, log_by_lua*, balancer_by_lua*

Returns a Lua table holding all the current response headers for the current request.

localh,err=ngx.resp.get_headers()iferr=="truncated"then-- one can choose to ignore or reject the current response hereendfork,vinpairs(h)do...end

This function has the same signature asngx.req.get_headers except getting response headers instead of request headers.

Note that a maximum of 100 response headers are parsed by default (including those with the same name) and that additional response headers are silently discarded to guard against potential denial of service attacks. Sincev0.10.13, when the limit is exceeded, it will return a second value which is the string"truncated".

This API was first introduced in thev0.9.5 release.

Back to TOC

syntax:is_internal = ngx.req.is_internal()

context:set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, log_by_lua*

Returns a boolean indicating whether the current request is an "internal request", i.e.,a request initiated from inside the current Nginx server instead of from the client side.

Subrequests are all internal requests and so are requests after internal redirects.

This API was first introduced in thev0.9.20 release.

Back to TOC

syntax:secs = ngx.req.start_time()

context:set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, log_by_lua*

Returns a floating-point number representing the timestamp (including milliseconds as the decimal part) when the current request was created.

The following example emulates the$request_time variable value (provided byngx_http_log_module) in pure Lua:

localrequest_time=ngx.now()-ngx.req.start_time()

This function was first introduced in thev0.7.7 release.

See alsongx.now andngx.update_time.

Back to TOC

syntax:num = ngx.req.http_version()

context:set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*

Returns the HTTP version number for the current request as a Lua number.

Current possible values are 3.0, 2.0, 1.0, 1.1, and 0.9. Returnsnil for unrecognized values.

This method was first introduced in thev0.7.17 release.

Back to TOC

syntax:str = ngx.req.raw_header(no_request_line?)

context:set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*

Returns the original raw HTTP protocol header received by the Nginx server.

By default, the request line and trailingCR LF terminator will also be included. For example,

ngx.print(ngx.req.raw_header())

gives something like this:

GET /t HTTP/1.1Host: localhostConnection: closeFoo: bar

You can specify the optionalno_request_line argument as atrue value to exclude the request line from the result. For example,

ngx.print(ngx.req.raw_header(true))

outputs something like this:

Host: localhostConnection: closeFoo: bar

This method was first introduced in thev0.7.17 release.

This method does not work in HTTP/2 requests yet.

Back to TOC

syntax:method_name = ngx.req.get_method()

context:set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, balancer_by_lua*, log_by_lua*

Retrieves the current request's request method name. Strings like"GET" and"POST" are returned instead of numericalmethod constants.

If the current request is an Nginx subrequest, then the subrequest's method name will be returned.

This method was first introduced in thev0.5.6 release.

See alsongx.req.set_method.

Back to TOC

syntax:ngx.req.set_method(method_id)

context:set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*

Overrides the current request's request method with themethod_id argument. Currently only numericalmethod constants are supported, likengx.HTTP_POST andngx.HTTP_GET.

If the current request is an Nginx subrequest, then the subrequest's method will be overridden.

This method was first introduced in thev0.5.6 release.

See alsongx.req.get_method.

Back to TOC

syntax:ngx.req.set_uri(uri, jump?, binary?)

context:set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*

Rewrite the current request's (parsed) URI by theuri argument. Theuri argument must be a Lua string and cannot be of zero length, or a Lua exception will be thrown.

The optional booleanjump argument can trigger location rematch (or location jump) asngx_http_rewrite_module'srewrite directive, that is, whenjump istrue (default tofalse), this function will never return and it will tell Nginx to try re-searching locations with the new URI value at the laterpost-rewrite phase and jumping to the new location.

Location jump will not be triggered otherwise, and only the current request's URI will be modified, which is also the default behavior. This function will return but with no returned values when thejump argument isfalse or absent altogether.

For example, the following Nginx config snippet

rewrite ^ /foo last;

can be coded in Lua like this:

ngx.req.set_uri("/foo",true)

Similarly, Nginx config

rewrite ^ /foobreak;

can be coded in Lua as

ngx.req.set_uri("/foo",false)

or equivalently,

ngx.req.set_uri("/foo")

Thejump argument can only be set totrue inrewrite_by_lua*. Use of jump in other contexts is prohibited and will throw out a Lua exception.

A more sophisticated example involving regex substitutions is as follows

location /test{     rewrite_by_lua_block{         local uri = ngx.re.sub(ngx.var.uri,"^/test/(.*)","/$1","o")         ngx.req.set_uri(uri)}proxy_passhttp://my_backend;}

which is functionally equivalent to

location /test{rewrite ^/test/(.*) /$1break;proxy_passhttp://my_backend;}

Note: this function throws a Lua error if theuri argumentcontains unsafe characters (control characters).

Note that it is not possible to use this interface to rewrite URI arguments and thatngx.req.set_uri_args should be used for this instead. For instance, Nginx config

rewrite ^ /foo?a=3? last;

can be coded as

 ngx.req.set_uri_args("a=3") ngx.req.set_uri("/foo", true)

or

 ngx.req.set_uri_args({a = 3}) ngx.req.set_uri("/foo", true)

Starting from0.10.16 of this module, this function accepts anoptional booleanbinary argument to allow arbitrary binary URIdata. By default, thisbinary argument is false and this functionwill throw out a Lua error such as the one below when theuriargument contains any control characters (ASCII Code 0 ~ 0x08, 0x0A ~ 0x1F and 0x7F).

[error] 23430#23430: *1 lua entry thread aborted: runtime error:content_by_lua(nginx.conf:44):3: ngx.req.set_uri unsafe byte "0x00"in "\x00foo" (maybe you want to set the 'binary' argument?)

This interface was first introduced in thev0.3.1rc14 release.

Back to TOC

syntax:ngx.req.set_uri_args(args)

context:set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*

Rewrite the current request's URI query arguments by theargs argument. Theargs argument can be either a Lua string, as in

ngx.req.set_uri_args("a=3&b=hello%20world")

or a Lua table holding the query arguments' key-value pairs, as in

ngx.req.set_uri_args({a=3,b="hello world"})

In the former case, i.e., when the whole query-string is provided directly,the input Lua string should already be well-formed with the URI encoding.For security considerations, this method will automatically escape any control andwhitespace characters (ASCII code 0x00 ~ 0x20 and 0x7F) in the Lua string.

In the latter case, this method will escape argument keys and values according to the URI escaping rule.

Multi-value arguments are also supported:

ngx.req.set_uri_args({a=3,b= {5,6} })

which will result in a query string likea=3&b=5&b=6 orb=5&b=6&a=3.

Note that when using Lua table as thearg argument, the order of the arguments in the result query string which change from time to time. If you would like to get an ordered result, you need to use Lua string as thearg argument.

This interface was first introduced in thev0.3.1rc13 release.

See alsongx.req.set_uri.

Back to TOC

syntax:args, err = ngx.req.get_uri_args(max_args?, tab?)

context:set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, log_by_lua*, balancer_by_lua*

Returns a Lua table holding all the current request URL query arguments. An optionaltab argumentcan be used to reuse the table returned by this method.

location = /test{     content_by_lua_block{         local args, err = ngx.req.get_uri_args()if err =="truncated" then             -- one can choose to ignore or reject the current request here         endfor key, val in pairs(args) doif type(val) =="table" then                 ngx.say(key,": ", table.concat(val,", "))             else                 ngx.say(key,": ", val)             end         end}}

ThenGET /test?foo=bar&bar=baz&bar=blah will yield the response body

 foo: bar bar: baz, blah

Multiple occurrences of an argument key will result in a table value holding all the values for that key in order.

Keys and values are unescaped according to URI escaping rules. In the settings above,GET /test?a%20b=1%61+2 will yield:

 a b: 1a 2

Arguments without the=<value> parts are treated as boolean arguments.GET /test?foo&bar will yield:

 foo:true bar:true

That is, they will take Lua boolean valuestrue. However, they are different from arguments taking empty string values.GET /test?foo=&bar= will give something like

 foo: bar:

Empty key arguments are discarded.GET /test?=hello&=world will yield an empty output for instance.

Updating query arguments via the Nginx variable$args (orngx.var.args in Lua) at runtime is also supported:

ngx.var.args="a=3&b=42"localargs,err=ngx.req.get_uri_args()

Here theargs table will always look like

 {a=3,b=42}

regardless of the actual request query string.

Note that a maximum of 100 request arguments are parsed by default (including those with the same name) and that additional request arguments are silently discarded to guard against potential denial of service attacks. Sincev0.10.13, when the limit is exceeded, it will return a second value which is the string"truncated".

However, the optionalmax_args function argument can be used to override this limit:

localargs,err=ngx.req.get_uri_args(10)iferr=="truncated"then-- one can choose to ignore or reject the current request hereend

This argument can be set to zero to remove the limit and to process all request arguments received:

localargs,err=ngx.req.get_uri_args(0)

Removing themax_args cap is strongly discouraged.

Back to TOC

syntax:args, err = ngx.req.get_post_args(max_args?)

context:rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, log_by_lua*

Returns a Lua table holding all the current request POST query arguments (of the MIME typeapplication/x-www-form-urlencoded). Callngx.req.read_body to read the request body first or turn on thelua_need_request_body directive to avoid errors.

location = /test{     content_by_lua_block{         ngx.req.read_body()         local args, err = ngx.req.get_post_args()if err =="truncated" then             -- one can choose to ignore or reject the current request here         endif not args then             ngx.say("failed to get post args: ", err)return         endfor key, val in pairs(args) doif type(val) =="table" then                 ngx.say(key,": ", table.concat(val,", "))             else                 ngx.say(key,": ", val)             end         end}}

Then

# Post request with the body 'foo=bar&bar=baz&bar=blah' $ curl --data'foo=bar&bar=baz&bar=blah' localhost/test

will yield the response body like

 foo: bar bar: baz, blah

Multiple occurrences of an argument key will result in a table value holding all of the values for that key in order.

Keys and values will be unescaped according to URI escaping rules.

With the settings above,

# POST request with body 'a%20b=1%61+2' $ curl -d'a%20b=1%61+2' localhost/test

will yield:

 a b: 1a 2

Arguments without the=<value> parts are treated as boolean arguments.POST /test with the request bodyfoo&bar will yield:

 foo:true bar:true

That is, they will take Lua boolean valuestrue. However, they are different from arguments taking empty string values.POST /test with request bodyfoo=&bar= will return something like

 foo: bar:

Empty key arguments are discarded.POST /test with body=hello&=world will yield empty outputs for instance.

Note that a maximum of 100 request arguments are parsed by default (including those with the same name) and that additional request arguments are silently discarded to guard against potential denial of service attacks. Sincev0.10.13, when the limit is exceeded, it will return a second value which is the string"truncated".

However, the optionalmax_args function argument can be used to override this limit:

localargs,err=ngx.req.get_post_args(10)iferr=="truncated"then-- one can choose to ignore or reject the current request hereend

This argument can be set to zero to remove the limit and to process all request arguments received:

localargs,err=ngx.req.get_post_args(0)

Removing themax_args cap is strongly discouraged.

Back to TOC

syntax:headers, err = ngx.req.get_headers(max_headers?, raw?)

context:set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*, log_by_lua*

Returns a Lua table holding all the current request headers.

localh,err=ngx.req.get_headers()iferr=="truncated"then-- one can choose to ignore or reject the current request hereendfork,vinpairs(h)do...end

To read an individual header:

ngx.say("Host:",ngx.req.get_headers()["Host"])

Note that thengx.var.HEADER API call, which uses core$http_HEADER variables, may be more preferable for reading individual request headers.

For multiple instances of request headers such as:

 Foo: foo Foo: bar Foo: baz

the value ofngx.req.get_headers()["Foo"] will be a Lua (array) table such as:

 {"foo","bar","baz"}

Note that a maximum of 100 request headers are parsed by default (including those with the same name) and that additional request headers are silently discarded to guard against potential denial of service attacks. Sincev0.10.13, when the limit is exceeded, it will return a second value which is the string"truncated".

However, the optionalmax_headers function argument can be used to override this limit:

localheaders,err=ngx.req.get_headers(10)iferr=="truncated"then-- one can choose to ignore or reject the current request hereend

This argument can be set to zero to remove the limit and to process all request headers received:

localheaders,err=ngx.req.get_headers(0)

Removing themax_headers cap is strongly discouraged.

Since the0.6.9 release, all the header names in the Lua table returned are converted to the pure lower-case form by default, unless theraw argument is set totrue (default tofalse).

Also, by default, an__index metamethod is added to the resulting Lua table and will normalize the keys to a pure lowercase form with all underscores converted to dashes in case of a lookup miss. For example, if a request headerMy-Foo-Header is present, then the following invocations will all pick up the value of this header correctly:

ngx.say(headers.my_foo_header)ngx.say(headers["My-Foo-Header"])ngx.say(headers["my-foo-header"])

The__index metamethod will not be added when theraw argument is set totrue.

Back to TOC

syntax:ngx.req.set_header(header_name, header_value)

context:set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*

Set the current request's request header namedheader_name to valueheader_value, overriding any existing ones.

The input Lua stringheader_name andheader_value should already be well-formed with the URI encoding.For security considerations, this method will automatically escape " ", """, "(", ")", ",", "/", ":", ";", "?","<", "=", ">", "?", "@", "[", "]", "", "{", "}", 0x00-0x1F, 0x7F-0xFF inheader_name and automatically escape"0x00-0x08, 0x0A-0x0F, 0x7F inheader_value.

By default, all the subrequests subsequently initiated byngx.location.capture andngx.location.capture_multi will inherit the new header.

It is not a Lua's equivalent of nginxproxy_set_header directive (same is true aboutngx.req.clear_header).proxy_set_header only affects the upstream request whilengx.req.set_header change the incoming request. Record the http headers in the access log file will show the difference. But you still can use it as an alternative of nginxproxy_set_header directive as long as you know the difference.

Here is an example of setting theContent-Type header:

ngx.req.set_header("Content-Type","text/css")

Theheader_value can take an array list of values,for example,

ngx.req.set_header("Foo", {"a","abc"})

will produce two new request headers:

 Foo: a Foo: abc

and oldFoo headers will be overridden if there is any.

When theheader_value argument isnil, the request header will be removed. So

ngx.req.set_header("X-Foo",nil)

is equivalent to

ngx.req.clear_header("X-Foo")

Note: this function throws a Lua error ifheader_name orheader_value contain unsafe characters (control characters).

Back to TOC

syntax:ngx.req.clear_header(header_name)

context:set_by_lua*, rewrite_by_lua*, access_by_lua*, content_by_lua*, header_filter_by_lua*, body_filter_by_lua*

Clears the current request's request header namedheader_name. None of the current request's existing subrequests will be affected but subsequently initiated subrequests will inherit the change by default.

Back to TOC

syntax:ngx.req.read_body()

context:rewrite_by_lua*, access_by_lua*, content_by_lua*

Reads the client request body synchronously without blocking the Nginx event loop.

ngx.req.read_body()localargs=ngx.req.get_post_args()

If the request body is already read previously by turning onlua_need_request_body or by using other modules, then this function does not run and returns immediately.

If the request body has already been explicitly discarded, either by thengx.req.discard_body function or other modules, this function does not run and returns immediately.

In case of errors, such as connection errors while reading the data, this method will throw out a Lua exceptionor terminate the current request with a 500 status code immediately.

The request body data read using this function can be retrieved later viangx.req.get_body_data or, alternatively, the temporary file name for the body data cached to disk usingngx.req.get_body_file. This depends on

1. whether the current request body is already larger than theclient_body_buffer_size,
2. and whetherclient_body_in_file_only has been switched on.

In cases where current request may have a request body and the request body data is not required, Thengx.req.discard_body function must be used to explicitly discard the request body to avoid breaking things under HTTP 1.1 keepalive or HTTP 1.1 pipelining.

This function was first introduced in thev0.3.1rc17 release.