Someone needs to write this.
mod_lua provides a handler named lua-script,
which can be used with an AddHandler directive:
This will cause any .lua file to be evaluated by
mod_lua.
mod_lua always looks to invoke a function for the handler, rather than
just evaluating a script body CGI style. A handler function looks
something like this:
require "string"
function handle_something(r)
r.content_type = "text/plain"
r:puts("Hello Lua World!\n")
if r.method == 'GET' then
for k, v in pairs( r:parseargs() ) do
r:puts( string.format("%s: %s", k, v) )
end
elseif r.method == 'POST' then
for k, v in pairs( r:parsebody() ) do
r:puts( string.format("%s: %s", k, v) )
end
else
r:puts("unknown HTTP method " .. r.method)
end
end
This handler function just prints out the uri or form encoded arguments to a plaintext page.
This means (and in fact encourages) that you can have multiple handlers (or hooks, or filters) in the same script.
The request_rec is mapped in as a userdata. It has a metatable which lets you do useful things with it. For the most part it has the same fields as the request_rec struct (see httpd.h until we get better docs here) many of which are writeable as well as readable, and has (at least) the following methods:
Specify the base path which will be used to evaluate all relative paths within mod_wombat. If not specified they will be resolved relative to the current working directory, which may not always work well for a server.
Specify the lifecycle scope of the Lua interpreter which will be used by handlers in this "Directory." The default is "once"
This directive matches a uri pattern to invoke a specific handler function in a specific file. It uses PCRE regular expressions to match the uri, and supports interpolating match groups into both the file path and the function name be careful writing your regular expressions to avoid security issues.
This would match uri's such as /photos/show?id=9 to the file /scripts/photos.lua and invoke the handler function handle_show on the lua vm after loading that file.
This would invoke the "handle" function, which is the default if no specific function name is provided.
Add a path to lua's module search path. Follows the same conventions as lua. This just munges the package.path in the lua vms.
Add a path to lua's shared library search path. Follows the same conventions as lua. This just munges the package.cpath in the lua vms.
Specify the behavior of the in-memory code cache. The default is stat, which stats the top level script (not any included ones) each time that file is needed, and reloads it if the modified time indicates it is newer than the one it has already loaded. The other values cause it to keep the file cached forever (don't stat and replace) or to never cache the file.
In general stat or forever is good production and stat or never for deveopment.
Add a hook (at APR_HOOK_MIDDLE) to the translate name phase of request processing. The hook function receives a single argument, the request_rec, and should return a status code, which is either an HTTP error code, or the constants defined in the apache2 module: apache2.OK, apache2.DECLINED, or apache2.DONE.
For those new to hooks, basically each hook will be invoked until one of them returns apache2.OK. If your hook doesn't want to do the translation it should just return apache2.DECLINED. If the request should stop processing, then return apache2.DONE.
Example:
...
...
...
...
...
...
Not Yet Implemented
...