This directive specifies the lookup path for Lua scripts used in set_by_lua, content_by_lua, and other directives.

This directive creates a Lua dictionary that is shared across all NGINX workers.

This directive specifies the Lua code (as a string) executed by NGINX's master process at the global Lua VM level. The code can register Lua's global variables and import Lua modules that can be used later in other Lua directives. Here's an example:

init_by_lua 'cjson = require "cjson"';

The init_by_lua_file directive is similar to init_by_lua. It executes the code specified in a file to set the global context. Both directives are available under the http section of an NGINX configuration.

This directive specifies the Lua code (as a string), a return variable, and certain optional arguments. It executes the code using the passed arguments and provides the value in the specified variable. Here's an example:

set_by_lua $sum 'return (10 + 20)';
echo $sum; 

Arguments passed to the Lua code can be accessed using the ngx.arg[i] directive. The directive can only return a single value from the code. If multiple values are required, we need to use the ngx.var.VariableName directive to create multiple variables. Here's an example:

set_by_lua $sum 'return (ngx.arg[1] + ngx.arg[2])' 10 20;
echo $sum;

The set_by_lua_file directive is similar to set_by_lua. It executes the code specified in a file using optional parameters and returns the value in the specified variable. Both directives are available under the if (in location), location, and server sections of an NGINX configuration.

This directive acts as a content provider and executes the Lua code (as a string) to generate an NGINX response. It is important to note that the directive must not be used with other content handles, such as Proxy, in the same location block.

The content_by_lua_file directive is similar to content_by_lua. It executes the code specified in a file to generate an NGINX response. Both directives are available under the location and if (in location) sections of an NGINX configuration. Here's an example:

location /content {
   content_by_lua 'ngx.say("hello ! Content from lua")';
}

NGINX allows the manipulation of response headers using Lua. The code can add new header fields or manipulate/delete existing response headers. The header_filter_by_lua directive executes the Lua code as a response header filter. The code can access response headers using ngx.header.HeaderFieldName variable.

The header_filter_by_lua_file directive is similar to header_filter_by_lua. It executes the code specified in a file to manipulate response headers. Both directives are available under the http, server, location, and if (in location) sections of an NGINX configuration. Here's an example:

location /content {
   content_by_lua 'ngx.say("hello ! Content from lua")';
   header_filter_by_lua 'ngx.header.X-Source = "LuaScript"';
}

The directive executes during the output-body-filter phase of NGINX and can be used to manipulate the output body. The complete response body is passed in the ngx.arg[1] variable. The Lua code can alter the contents of the variable to return a new output body. The ngx.arg[2] variable contains the eof flag.

The body_filter_by_lua_file directive is similar to body_filter_by_lua. It executes the code specified in a file to filter the output body. Both directives are available under the http, server, location, and if (in location) sections of an NGINX configuration. Here's an example:

location /content {
   content_by_lua 'ngx.say("hello ! Content from lua")';
   header_filter_by_lua 'ngx.header.content_length = nil';
   body_filter_by_lua 'ngx.arg[1]=string.upper("from body filer"..ngx.arg[1]) ';
}

The directive executes the Lua code during the access phase of NGINX after the execution of ngx_http_access_module.

The access_by_lua_file directive is similar to access_by_lua. It executes code specified in a file to determine access. Both directives are available under the http, server, location, and if (in location) sections of an NGINX configuration. Here's an example:

location /content {
   content_by_lua 'ngx.say("hello ! Content from lua")';
   access_by_lua ' if ngx.var.remote_addr == "192.168.2.111" then 
          ngx.exit(ngx.HTTP_FORBIDDEN) 
        end'; 
}

The rewrite_by_lua directive executes Lua code during the rewrite phase of NGINX after the execution of ngx_http_rewrite_module.

The rewrite_by_lua_file directive is similar to rewrite_by_lua. It executes the code specified in a file during the rewrite phase. Both directives are available under the http, server, location, and if (in location) sections of an NGINX configuration. Here's an example:

location /content {
   content_by_lua 'ngx.say("hello ! Content from lua")';
   rewrite_by_lua ' if ngx.var.remote_addr == "192.168.2.111" then 
          ngx.redirect("/forbidden.html") 
        end'; 
}

The log_by_lua directive executes the Lua code during the log request phase of NGINX. The code does not replace NGINX access logs, but can do sundry things, such as tracking request times, logging messages, and so on. The messages logged using ngx.log() will be sent to the NGINX error log. It is important to note that the request body is not accessible in this API.

The log_by_lua_file directive is similar to log_by_lua. It executes the code specified in a file during the log-request phase. Both directives are available under the http, server, location, and if (in location) sections of an NGINX configuration. Here's an example:

location /content {
   echo "hello world!"
   log_by_lua 'ngx.log(ngx.NOTICE,"logging request response")';
}