The lwt-wsapi handler provided by mod_lwt handles requests to the HTTP server by invoking a Lua script using WSAPI. More formally, the handler performs the following steps:
- Test if the request is supposed to be handled by
lwt-wsapi. If not, decline to handle the request. - Test if the Lua script file exists. If not, return a HTTP 404 (Not Found) status code.
- Default the response content type to
text/html. - Create a new Lua state.
- Open the standard Lua libraries in the Lua state.
- Open the
httpd.corelibrary in the Lua state. (This is an internal library that is exposed to scripts by thehttpdmodule.) - Set the
package.pathandpackage.cpathvariables according to the configuration directives applicable to the script. - Open the
httpd.wsapilibrary in the Lua state. - Invoke the
httpd.wsapi.runfunction, passing the request and env values as detailed below. This function then invokeswsapi.common.runto let WSAPI handle the request.
This example shows a simple WSAPI Lua script:
module(..., package.seeall)
function run(wsapi_env)
local headers = { ["Content-type"] = "text/html" }
local function hello_text()
coroutine.yield("<html><body>")
coroutine.yield("<p>Hello Wsapi!</p>")
coroutine.yield("<p>PATH_INFO: " .. wsapi_env.PATH_INFO .. "</p>")
coroutine.yield("<p>SCRIPT_NAME: " .. wsapi_env.SCRIPT_NAME .. "</p>")
coroutine.yield("</body></html>")
end
return 200, headers, coroutine.wrap(hello_text)
end
The request value is identical to the request value passed by the lwt handler.
The env value is a table-like userdata value (APR table) and contains the subprocess environement (aka CGI environment) of the current request.
The fields of the env value can be accessed by name (e.g. env.field) or by iterating over the arguments using the httpd.pairs function.
