50 lines
1.8 KiB
Plaintext
50 lines
1.8 KiB
Plaintext
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:
|
|
|
|
-- example.lua --
|
|
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.
|
|
|
|
Data Structures:
|
|
request_rec:
|
|
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:
|
|
|
|
r:puts("hello", " world", "!") -- print to response body
|
|
|
|
-- logging functions
|
|
r:debug("This is a debug log message")
|
|
r:info("This is an info log message")
|
|
r:notice("This is an notice log message")
|
|
r:warn("This is an warn log message")
|
|
r:err("This is an err log message")
|
|
r:alert("This is an alert log message")
|
|
r:crit("This is an crit log message")
|
|
r:emerg("This is an emerg log message")
|