| 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") |