Lua can be used to generate configs (like a shortcut to "@include_shell@":core_config.html#core_config__includes) or to write actual response handlers. Using Lua to generate configs doesn't have any performance impact; in this case Lua is only run at startup to generate the config, and there is no Lua involved for processing requests. As a @lua_State@ itself is not thread-safe, you have two ways to use Lua configs: * "@include_lua@":core_config.html#core_config__includes and "@lua.plugin@":mod_lua.html#mod_lua__setup_lua-plugin : using a global server lock, but with sharing the same @lua_State@ in all workers * "@lua_handler@":mod_lua.html#mod_lua__action_lua-handler: without locking, and every worker has its own @lua_State@ (and they cannot share their global context).
This section describe how to translate concepts from the main config to Lua. You can write the whole config in Lua or only parts and include them (for example with "@include_lua@":core_config.html#core_config__includes).
== | @:eq@ | != | @:ne@ | | <= | @:le@ | < | @:lt@ | | >= | @:ge@ | > | @:gt@ | | =~ | @:match@ | !~ | @:nomatch@ | | =^ | @:prefix@ | !^ | @:notprefix@ | | =$ | @:suffix@ | !$ | @:notsuffix@ | | =/ | @:ip@ | !/ | @:notip@ | Boolean condition variables are called with @:is()@ or @:isnot()@. The result of such call (a "condition") is then passed as first parameter to "@action.when@":plugin_core#plugin_core__action_when. ]]> Translating @if req.env["REMOTE_USER"] != "admin" { auth.deny; }@ to Lua: Translating @if !phys.exists { auth.deny; }@ to Lua:
e = vr.env e["XXX"] = "abc" Fields tagged with (ro) are read only; that does not mean the fields value can't be modified, you only cannot overwrite the field with another object. Readonly string / number properties are really read only though. Call object methods with @:method(...)@: 
			vr:print("Hello World")
*Note*: The @obj:method(par1, par2, ...)@ syntax is just another way to say @obj["method"](obj, par1, par2, ...)@ (but @obj@ is only evaluated once), so field and method names live in the same namespace. This means that our container types cannot provide access to fields which have the same names as the methods (and the methods starting with "__" are not listed here), so you have to use explicit access methods to read generic fields in such containers (write is not a problem as we don't allow writing methods). All container types should provide a @get@ and a @set@ method to provide "clean" access to the container contents. h3. pairs() Some objects may provide a @:pairs()@ method to loop through the fields (not the methods); this works for simple things like 
			for k, v in vr.env:pairs() do
			  vr:print("env['" .. k .. "'] = '" .. v .. "'")
			end
lua expects that the @:pairs@ method returns a @next, obj, startkey@ tuple and loops through the list with @k = startkey; while k, v = next(obj, k) do ... end@; but the @next()@ method is supposed to use @k@ as previous key and to return the next one. Our @next@ methods will keep the current position in an internal object (associated with the @next@ function as upvalue), and will advance on every call ignoring the @obj@ and @k@ parameter. ]]>
x = env["set"] -- doesn't work, returns the set method instead x = env:get("set") -- use this instead x = env[y] -- don't do this, as y may be a special key like "set" x = env:get(y) -- just do it the safe way if you are not sure Methods: * @get(k)@: safe way for @env[k]@ * @set(k, v)@: safe way for @env[k] = v@ * @unset(k)@: safe way for @env[k] = nil@ * @weak_set(k, v)@: don't override old value, safe way for @env[k] = env[k] or v@ * @pairs()@: use to loop through keys: @for k, v in env:pairs() do ... end@ * @clear()@: remove all entries ]]>