1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
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")
|
