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