La directive de base pour le chargement du module est

mod_lua fournit un gestionnaire nommé lua-script qui peut être utilisé avec une directive AddHandler :

Ceci aura pour effet de faire traiter les requêtes pour les fichiers dont l'extension est .lua par mod_lua en invoquant cette fonction de gestion de fichier.

Pour plus de détails, voir la directive LuaMapHandler.

Dans l'API du serveur HTTP Apache, un gestionnaire est une sorte de point d'accroche (hook) spécifique responsable de la génération de la réponse. mod_proxy, mod_cgi et mod_status sont des exemples de modules comportant un gestionnaire.

mod_lua cherche toujours à invoquer une fonction Lua pour le gestionnaire, plutôt que de simplement évaluer le corps d'un script dans le style de CGI. Une fonction de gestionnaire se présente comme suit :

-- exemple de gestionnaire

require "string"

--[[
     Il s'agit du nom de méthode par défaut pour les gestionnaires Lua ;
     voir les noms de fonctions optionnels dans la directive
     LuaMapHandler pour choisir un point d'entrée différent.
--]]
function handle(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

Ce gestionnaire se contente d'afficher les arguments codés d'un uri ou d'un formulaire dans un page au format texte.

Cela signifie que vous pouvez (et êtes encouragé à) avoir plusieurs gestionnaires (ou points d'entrée, ou filtres) dans le même script.

Les fonctions d'accroche déterminent la manière dont les modules (et les scripts Lua) participent au traitement des requêtes. Chaque type d'accroche proposé par le serveur a un rôle spécifique, comme l'association de requêtes au système de fichiers, le contrôle d'accès, ou la définition de types MIME. Il existe aussi des accroches à usage général qui s'exécutent simplement à des moments opportuns du cycle de vie de la requête.

Les fonctions d'accroche acceptent l'objet de la requête comme seul et unique argument. Elles peuvent renvoyer une valeur, selon la fonction, mais il s'agit en général d'un code d'état HTTP ou des valeurs OK, DONE, ou DECLINED, que vous pouvez écrire dans lua sous la forme apache2.OK, apache2.DONE, ou apache2.DECLINED.

-- exemple d'accroche qui réécrit un URI en chemin du système de
fichiers.

require 'apache2'

function translate_name(r)
    if r.uri == "/translate-name" then
        r.filename = r.document_root .. "/find_me.txt"
        return apache2.OK
    end
    -- on ne gère pas cette URL et on donne sa chance à un autre module
    return apache2.DECLINED
end

--[[ exemple d'accroche qui réécrit un URI vers un autre URI. Il renvoie
	un apache2.DECLINED pour permettre à un autre interpréteur d'URL de
	travailler sur la substitution, y compris l'accroche translate_name
	de base dont les tables de correspondances se basent sur DocumentRoot.

     Note: actuellement, il est impossible de prévoir si cette action
     s'exécute avant ou après mod_alias.
--]]

require 'apache2'

function translate_name(r)
    if r.uri == "/translate-name" then
        r.uri = "/find_me.txt"
        return apache2.DECLINED
    end
    return apache2.DECLINED
end

request_rec

request_rec est considérée en tant que donnée utilisateur. Elle possède une métatable qui vous permet d'accomplir des choses intéressantes. Pour la plus grande partie, elle possède les mêmes champs que la structure request_rec (voir httpd.h en attendant que cette documentation soit plus complète), la plupart d'entre eux étant accessibles en lecture et écriture (le contenu des champs de la table peut être modifié, mais les champs eux-mêmes ne peuvent pas être établis en tant que tables distinctes).

Nom	Type Lua	Modifiable
ap_auth_type	string	non
args	string	oui
assbackwards	boolean	non
canonical_filename	string	non
content_encoding	string	non
content_type	string	oui
document_root	string	non
err_headers_out	table	non
filename	string	oui
handler	string	oui
headers_in	table	oui
headers_out	table	oui
hostname	string	non
method	string	non
notes	table	oui
path_info	string	non
protocol	string	non
proxyreq	string	oui
range	string	non
subprocess_env	table	oui
status	number	oui
the_request	string	non
unparsed_uri	string	non
uri	string	oui
user	string	oui

La structure request_rec possède (au minimum) les méthodes suivantes :

r:addoutputfilter(name|function) -- ajoute un filtre en sortie r:parseargs() -- renvoie une table lua contenant les arguments de la chaîne de paramètres de la requête r:parsebody() -- interprète le corps de la requête en tant que méthode POST et renvoie une table lua r:puts("bonjour", " le monde", "!") -- affichage dans le corps de la réponse r:write("une simple chaîne") -- affichage dans le corps de la réponse

Le paquet nommé apache2 est fourni avec (au minimum) le contenu suivant :

apache2.OK

Constante interne OK. Les gestionnaires renverront cette valeur s'ils ont traité la requête.

apache2.DECLINED

Constante interne DECLINED. Les gestionnaires renverront cette valeur s'ils n'ont pas l'intention de traiter la requête.

apache2.DONE

Constante interne DONE.

apache2.version

Chaîne contenant la version du serveur HTTP Apache

apache2.HTTP_MOVED_TEMPORARILY

Code d'état HTTP

apache2.PROXYREQ_NONE, apache2.PROXYREQ_PROXY, apache2.PROXYREQ_REVERSE, apache2.PROXYREQ_RESPONSE

Constantes internes utilisées par mod_proxy

Les autres codes d'état HTTP ne sont pas encore implémentés.