mod_lua

mod_lua load lua plugins and actions

lua.plugin (setup)

load file as lua plugin

lua.plugin (filename, options, lua-args);

filename: the file containing the lua code
options: A key-value table with options; no options available yet
lua-args: arguments forwarded to the lua plugin

A lua plugin can register setup and action callbacks (like any C module) by creating a setups / actions table in the global lua namespace.

The filename and the third argument lua-args are available as parameters in ... in the lua script.

Example

setup {
	module_load "mod_lua";
	lua.plugin "secdownload.lua";
}

Example plugin

(see contrib/core.lua for a real example)

local filename, args = ...

-- args are from the lua.plugin line

local function simple(actionarg)
	-- actionarg is the parameter from the 'single "/xxx";' action line

	-- create an action:
	return action.respond()
end

actions = {
	["simple"] = simple,
}

lua.handler (action)

load file as lua config

lua.handler (filename, options, lua-args);

filename

the file containing the lua code

options

A key-value table with the following entries:

ttl: time in seconds after which the file is checked for modifications and reloaded. 0 disables reloading (default 0)

lua-args

arguments forwarded to the lua plugin

lua.handler is basically the same as include_lua with the following differences:

each worker loads the lua file itself
it isn’t loaded before it is used, so you won’t see errors in the script at load time
it cannot call setup functions
it supports arguments to the script (local filename, args = ...)
doesn’t lock the global lua lock, so it performs better when you use multiple workers

See contrib/core.lua for how we load some external actions like contrib/core__xsendfile.lua.

Example

setup {
	module_load "mod_lua";
	lua.plugin "secdownload.lua";
}

if req.path =^ "/app" {
	lua.handler "/etc/lighttpd/pathrewrite.lua", [ "ttl" => 300 ], "/app";
}