Serveur Apache HTTP Version 2.5
Description: | Fournit des points d'entrée Lua dans différentes parties du traitement des requêtes httpd |
---|---|
Statut: | Expérimental |
Identificateur de Module: | lua_module |
Fichier Source: | mod_lua.c |
Compatibilité: | versions 2.3 et supérieures |
Ce module permet d'ajouter au serveur des extensions sous forme de
scripts écrits dans le langage de programmation Lua.
mod_lua
fournit de nombreuses extensions
(hooks) disponibles avec les modules natifs du serveur HTTP Apache,
comme les associations de requêtes à des fichiers, la génération de
réponses dynamiques, le contrôle d'accès, l'authentification et
l'autorisation.
Vous trouverez davantage d'informations à propos du langage de programmation Lua sur le site web de Lua.
mod_lua
est encore au stade expérimental. Son mode
d'utilisation et son comportement pourront changer à tout moment jusqu'à
ce qu'il passe au stade stable, et ce même entre deux versions stables
2.4.x. N'oublez pas de consulter le fichier CHANGES avant toute mise à
jour.Ce module possède une grande capacité d'action sur le fonctrionnement de httpd, ce qui lui confère une grande puissance, mais peut aussi induire un risque de sécurité. Il est déconseillé d'utiliser ce module sur un serveur partagé avec des utilisateurs auxquels vous ne pouvez pas accorder une confiance absolue, car il peut permettre de modifier le fonctionnement interne de httpd.
La directive de base pour le chargement du module est
LoadModule lua_module modules/mod_lua.so
mod_lua
fournit un gestionnaire nommé
lua-script
qui peut être utilisé avec une directive
AddHandler
:
AddHandler lua-script .lua
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 :
example.lua
-- 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\n", k, v) ) end elseif r.method == 'POST' then for k, v in pairs( r:parsebody() ) do r:puts( string.format("%s: %s\n", k, v) ) end else r:puts("Unsupported 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.
mod_authz_core
fournit une interface d'autorisation
de haut niveau bien plus facile à utiliser que dans les hooks
correspondants. Le premier argument de la directive Require
permet de spécifier le
fournisseur d'autorisation à utiliser. Pour chaque directive Require
,
mod_authz_core
appellera le fournisseur d'autorisation
spécifié, le reste de la ligne constituant les paramètres. Le
fournisseur considéré va alors vérifier les autorisations et fournir le
résultat dans une valeur de retour.
En général, le fournisseur authz est appelé avant l'authentification.
S'il doit connaître le nom d'utilisateur authentifié (ou si
l'utilisateur est appelé à être authentifié), le fournisseur doit
renvoyer apache2.AUTHZ_DENIED_NO_USER
, ce qui va
déclancher le processus d'authentification et un deuxième appel du
fournisseur authz.
La fonction du fournisseur authz ci-dessous accepte deux arguments, une adresse IP et un nom d'utilisateur. Elle autorise l'accès dans le cas où la requête provient de l'adresse IP spécifiée, ou si l'utilisateur authentifié correspond au second argument :
authz_provider.lua
require 'apache2' function authz_check_foo(r, ip, user) if r.useragent_ip == ip then return apache2.AUTHZ_GRANTED elseif r.user == nil then return apache2.AUTHZ_DENIED_NO_USER elseif r.user == user then return apache2.AUTHZ_GRANTED else return apache2.AUTHZ_DENIED end end
La configuration suivante enregistre cette fonction en tant que
fournisseur foo
, et la configure por l'URL /
:
LuaAuthzProvider foo authz_provider.lua authz_check_foo <Location /> Require foo 10.1.2.3 john_doe </Location>
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 :
Phase d'accroche | Directive mod_lua | Description |
---|---|---|
Gestionnaire rapide | LuaQuickHandler |
Il s'agit de la première accroche appelée lorsqu'une requête a été associée à un serveur ou un serveur virtuel. |
Phase de traduction | LuaHookTranslateName |
Cette phase traduit l'URI de la requête en nom de fichier
sur le système. Ce sont des modules comme
mod_alias et mod_rewrite qui
interviennent au cours de cette phase. |
Choix du lieu de stockage de la ressource | LuaHookMapToStorage |
Cette phase définit le lieu de stockage de la ressource : physique, en cache ou externe/mandaté. Elle est assurée par les modules de mandat ou de mise en cache. |
Autorisation d'accès | LuaHookAccessChecker |
Cette phase vérifie si un client a l'autorisation d'accès à la ressource. Elle s'exécute avant l'authentification de l'utisateur ; il faut donc être prudent. |
Vérification de l'identifiant utilisateur | LuaHookCheckUserID |
Cette phase vérifie l'identifiant de l'utilisateur ayant fait l'objet d'une négociation. |
Vérification de l'autorisation d'accès | LuaHookAuthChecker
ou
LuaAuthzProvider |
Cette phase vérifie l'autorisation d'accès d'un utilisateur en fonction des ses paramètres de connexion, comme l'identifiant, le certificat, etc... |
Vérification du type de la ressource | LuaHookTypeChecker |
Cette phase assigne un type de contenu et un gestionnaire à la ressource. |
Derniers réglages | LuaHookFixups |
C'est la dernière phase avant l'activation des gestionnaires de contenu. Toute modification de dernière minute à la requête doit être effectuée ici. |
Gestionnaire de contenu | fichiers fx. .lua ou directive LuaMapHandler |
C'est durant cette phase que le contenu est traité. Les fichiers sont lus, interprétés, certains sont exécutés, et le résultat obtenu est envoyé au client. |
Journalisation | aucune | Lorsqu'une requête a été traitée, plusieurs phases de journalisation interviennent, et enregistrent leurs résultats dans les fichiers d'erreur ou d'accès. |
Les fonctions d'accroche reçoivent l'objet de la requête comme seul
argument (sauf LuaAuthzProvider qui reçoit aussi des arguments en
provenance de la directive Require). 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
.
translate_name.lua
-- 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
translate_name2.lua
--[[ 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: utilisez le drapeau early/late de la directive pour l'exécuter 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 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, 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 | Description |
---|---|---|---|
allowoverrides |
string | non | L'option AllowOverride s'applique à la requête courante. |
ap_auth_type |
string | non | Ce champ contient le type d'authentification effectuée
(par exemple basic ) |
args |
string | oui | La chaîne de paramètres de la requête (par exemple
foo=bar&name=johnsmith ) |
assbackwards |
boolean | non | contient true s'il s'agit d'une requête de style HTTP/0.9
(par exemple GET /foo (sans champs d'en-tête) ) |
auth_name |
string | non | La chaîne d'identification utilisée pour la vérification de l'autorisation d'accès (si elle est disponible). |
banner |
string | non | La bannière du serveur, par exemple Apache HTTP
Server/2.4.3 openssl/0.9.8c |
basic_auth_pw |
string | non | Le mot de passe pour l'authentification de base envoyé avec la requête, s'il existe |
canonical_filename |
string | non | Le nom de fichier canonique de la requête |
content_encoding |
string | non | Le type de codage du contenu de la requête courante |
content_type |
string | oui | Le type de contenu de la requête courante, tel qu'il a été
déterminé au cours de la phase type_check (par exemple
image/gif ou text/html ) |
context_prefix |
string | non | |
context_document_root |
string | non | |
document_root |
string | non | La racine des documents du serveur |
err_headers_out |
table | non | L'en-tête MIME de l'environnement pour la réponse, écrit même en cas d'erreur et conservé pendant les redirections internes |
filename |
string | oui | Le nom de fichier correspondant à la requête, par exemple /www/example.com/foo.txt. Il peut être modifié au cours des phases translate-name ou map-to-storage du traitement de la requête pour permettre au gestionnaire par défaut (ou aux gestionnaires de script) de servir une version du fichier autre que celle demandée. |
handler |
string | oui | Le nom du gestionnaire qui
doit traiter la requête, par exemple lua-script
si elle doit être traitée par mod_lua. Cette valeur est en
général définie via les directives AddHandler ou SetHandler , mais peut aussi l'être
via mod_lua pour permettre à un autre gestionnaire de traiter
une requête spécifique qui ne serait pas traitée par défaut
par ce dernier.
|
headers_in |
table | oui | Les en-têtes MIME de l'environnement de la requête. Il
s'agit des en-têtes comme Host, User-Agent,
Referer , etc... |
headers_out |
table | oui | Les en-têtes MIME de l'environnement de la réponse. |
hostname |
string | non | Le nom d'hôte, tel que défini par l'en-tête
Host: ou par un URI complet. |
is_https |
boolean | non | Indique si la requête à été faite via HTTPS |
is_initial_req |
boolean | non | Indique si la requête courante est la requête initiale ou une sous-requête. |
limit_req_body |
number | non | La taille maximale du corps de la requête, ou 0 si aucune limite. |
log_id |
string | non | L'identifiant de la requête dans les journaux d'accès ou d'erreur. |
method |
string | non | La méthode de la requête, par exemple GET ou
POST . |
notes |
table | oui | Une liste de notes qui peuvent être transmises d'un module à l'autre. |
options |
string | non | La valeur de la directive Options pour la requête courante. |
path_info |
string | non | La valeur de PATH_INFO extraite de la requête. |
port |
number | non | Le port du serveur utilisé par la requête. |
protocol |
string | non | Le protocole utilisé, par exemple HTTP/1.1 |
proxyreq |
string | oui | Indique s'il s'agit d'une requête mandatée ou non. Cette valeur est en général définie au cours de la phase post_read_request/translate_name du traitement de la requête. |
range |
string | non | Le contenu de l'en-tête Range: . |
remaining |
number | non | Le nombre d'octets du corps de la requête restant à lire. |
server_built |
string | non | La date de compilation du serveur. |
server_name |
string | non | Le nom du serveur pour cette requête. |
some_auth_required |
boolean | non | Indique si une autorisation est/était requise pour cette requête. |
subprocess_env |
table | oui | Le jeu de variables d'environnement pour cette requête. |
started |
number | non | Le moment où le serveur a été (re)démarré, en secondes depuis epoch (1er janvier 1970) |
status |
number | oui | Le code de retour (courant) pour cette requête, par
exemple 200 ou 404 . |
the_request |
string | non | La chaîne de la requête telle qu'elle a été envoyée par le
client, par exemple GET /foo/bar HTTP/1.1 . |
unparsed_uri |
string | non | La partie URI non interprétée de la requête |
uri |
string | oui | L'URI après interprétation par httpd |
user |
string | oui | Si une authentification a été effectuée, nom de l'utilisateur authentifié. |
useragent_ip |
string | non | L'adresse IP de l'agent qui a envoyé la requête |
La structure request_rec possède (au minimum) les méthodes suivantes :
r:flush() -- vide le tampon de sortie
r:addoutputfilter(name|function) -- ajoute un filtre en sortie
r:sendfile(filename) -- envoie un fichier entier au client en utilisant sendfile s'il est supporté par la plateforme
r:parseargs() -- renvoie une table Lua contenant la chaîne d'arguments de la requête
r:parsebody()([sizeLimit]) -- interprète le corps de la requête en tant que POST et renvoie une table lua. Un nombre optionnel peut être fourni pour spécifier le nombre maximal d'octets à interpréter. La valeur par défaut est 8192.
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
r:escape_html("<html>test</html>") -- Echappe le code HTML et renvoie le résultat
-- exemples de messages de journalisation r:trace1("Ceci est un message de journalisation de niveau trace") -- les niveaux valides vont de trace1 à trace8
r:debug("Ceci est un message de journalisation de niveau debug")
r:info("Ceci est un message de journalisation de niveau info")
r:notice("Ceci est un message de journalisation de niveau notice")
r:warn("Ceci est un message de journalisation de niveau warn")
r:err("Ceci est un message de journalisation de niveau err")
r:alert("Ceci est un message de journalisation de niveau alert")
r:crit("Ceci est un message de journalisation de niveau crit")
r:emerg("Ceci est un message de journalisation de niveau emerg")
Le paquet nommé apache2
est fourni avec (au minimum) le
contenu suivant :
mod_proxy
mod_authz_core
Les autres codes d'état HTTP ne sont pas encore implémentés.
Description: | Branche une fonction fournisseur d'autorisation dans mod_authz_core
|
---|---|
Syntaxe: | LuaAuthzProvider provider_name /path/to/lua/script.lua function_name |
Contexte: | configuration du serveur |
Statut: | Expérimental |
Module: | mod_lua |
Compatibilité: | Disponible depuis la version 2.4.3 du serveur HTTP Apache |
Lorsqu'une fonction lua a été enregistrée en tant que fournisseur
d'autorisation, elle peut être appelée via la directive Require
:
LuaRoot /usr/local/apache2/lua LuaAuthzProvider foo authz.lua authz_check_foo <Location /> Require foo johndoe </Location>
require "apache2" function authz_check_foo(r, who) if r.user ~= who then return apache2.AUTHZ_DENIED return apache2.AUTHZ_GRANTED end
Description: | Configure le cache de code compilé. |
---|---|
Syntaxe: | LuaCodeCache stat|forever|never |
Défaut: | LuaCodeCache stat |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | All |
Statut: | Expérimental |
Module: | mod_lua |
Cette directive permet de définir le comportement du cache de code en mémoire. La valeur par défaut est stat ; dans ce cas, le script du niveau le plus haut (et pas les scripts inclus) est vérifié à chaque fois que ce fichier est nécessaire, et est rechargé si la date de modification est plus récente que celle du script déjà chargé. Les autres valeurs permettent respectivement de garder le fichier en cache perpétuellement (forever - jamais vérifié ni remplacé), ou de ne jamais le mettre en cache (never).
En général, les valeurs stat et forever sont utilisées pour un serveur en production, et les valeurs stat ou never pour un serveur en développement.
LuaCodeCache stat LuaCodeCache forever LuaCodeCache never
Description: | Fournit un point d'entrée pour la phase access_checker du traitement de la requête |
---|---|
Syntaxe: | LuaHookAccessChecker /chemin/vers/lua/script.lua hook_function_name [early|late] |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | All |
Statut: | Expérimental |
Module: | mod_lua |
Compatibilité: | Le troisième argument optionnel est disponible depuis la version 2.3.15 du serveur HTTP Apache. |
Ajoute votre fonction d'accroche à la phase access_checker. Une fonction d'accroche access checker renvoie en général OK, DECLINED, ou HTTP_FORBIDDEN.
Les arguments optionnels "early" ou "late" permettent de contrôler le moment auquel ce script s'exécute par rapport aux autres modules.
Description: | Fournit un point d'entrée pour la phase auth_checker du traitement de la requête |
---|---|
Syntaxe: | LuaHookAuthChecker /chemin/vers/lua/script.lua hook_function_name [early|late] |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | All |
Statut: | Expérimental |
Module: | mod_lua |
Compatibilité: | Le troisième argument optionnel est disponible depuis la version 2.3.15 du serveur HTTP Apache. |
Invoque une fonction lua au cours de la phase auth_checker du traitement de la requête. Cette directive peut s'utiliser pour implémenter une vérification arbitraire de l'authentification et de l'autorisation. Voici un exemple très simple :
require 'apache2' -- fonction d'accroche authcheck fictive -- Si la requête ne contient aucune donnée d'authentification, l'en-tête -- de la réponse est défini et un code 401 est renvoyé afin de demander au -- navigateur d'effectuer une authentification basique. Si la requête -- comporte des données d'authentification, elles ne sont pas vraiment -- consultées, mais on admet la prise en compte de l'utilisateur 'foo' et -- on la valide. On vérifie ensuite si l'utilisateur est bien 'foo' et on -- accepte la requête. function authcheck_hook(r) -- recherche des informations d'authentification auth = r.headers_in['Authorization'] if auth ~= nil then -- définition d'un utilisateur par défaut r.user = 'foo' end if r.user == nil then r:debug("authcheck: user is nil, returning 401") r.err_headers_out['WWW-Authenticate'] = 'Basic realm="WallyWorld"' return 401 elseif r.user == "foo" then r:debug('user foo: OK') else r:debug("authcheck: user='" .. r.user .. "'") r.err_headers_out['WWW-Authenticate'] = 'Basic realm="WallyWorld"' return 401 end return apache2.OK end
Les arguments optionnels "early" ou "late" permettent de contrôler le moment auquel ce script s'exécute par rapport aux autres modules.
Description: | Fournit un point d'entrée pour la phase check_user_id du traitement de la requête |
---|---|
Syntaxe: | LuaHookCheckUserID /chemin/vers/lua/script.lua hook_function_name [early|late] |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | All |
Statut: | Expérimental |
Module: | mod_lua |
Compatibilité: | Le troisième argument optionnel est disponible depuis la version 2.3.15 du serveur HTTP Apache. |
...
Les arguments optionnels "early" ou "late" permettent de contrôler le moment auquel ce script s'exécute par rapport aux autres modules.
Description: | Fournit un point d'entrée pour la phase de correction du traitement de la requête |
---|---|
Syntaxe: | LuaHookFixups /chemin/vers/lua/script.lua hook_function_name |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | All |
Statut: | Expérimental |
Module: | mod_lua |
Idem LuaHookTranslateName, mais s'exécute durant la phase de correction.
Description: | Fournit un point d'entrée pour la phase insert_filter du traitement de la requête |
---|---|
Syntaxe: | LuaHookInsertFilter /chemin/vers/lua/script.lua hook_function_name |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | All |
Statut: | Expérimental |
Module: | mod_lua |
Non encore implémenté
Description: | Fournit un point d'entrée pour la phase map_to_storage du traitement de la requête |
---|---|
Syntaxe: | LuaHookMapToStorage /chemin/vers/lua/script.lua hook_function_name |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | All |
Statut: | Expérimental |
Module: | mod_lua |
Identique à la directive
LuaHookTranslateName
, mais s'exécute à la
phase map-to-storage du traitement de la requête. Les modules comme
mod_cache agissent pendant cette phase, ce qui permet de présenter
un exemple intéressant de ce que l'on peut faire ici :
LuaHookMapToStorage /path/to/lua/script.lua check_cache
require"apache2" cached_files = {} function read_file(filename) local input = io.open(filename, "r") if input then local data = input:read("*a") cached_files[filename] = data file = cached_files[filename] input:close() end return cached_files[filename] end function check_cache(r) if r.filename:match("%.png$") then -- Only match PNG files local file = cached_files[r.filename] -- Check cache entries if not file then file = read_file(r.filename) -- Read file into cache end if file then -- If file exists, write it out r.status = 200 r:write(file) r:info(("Sent %s to client from cache"):format(r.filename)) return apache2.DONE -- skip default handler for PNG files end end return apache2.DECLINED -- If we had nothing to do, let others serve this. end
Description: | Fournit un point d'entrée à la phase du nom de traduction du traitement de la requête |
---|---|
Syntaxe: | LuaHookTranslateName /chemin/vers/lua/script.lua nom_fonction_hook [early|late] |
Contexte: | configuration du serveur, serveur virtuel |
AllowOverride: | All |
Statut: | Expérimental |
Module: | mod_lua |
Compatibilité: | Le troisième argument optionnel est disponible depuis la version 2.3.15 du serveur HTTP Apache. |
Cette directive permet d'ajouter un point d'entrée (à APR_HOOK_MIDDLE) à la phase du nom de traduction du traitement de la requête. La fonction hook accepte un seul argument, le request_rec, et doit renvoyer un code d'état qui est soit un code d'erreur HTTP, ou une constante définie dans le module apache2 : apache2.OK, apache2.DECLINED, ou apache2.DONE.
Pour ceux qui ne sont pas familiers avec les points d'entrée (hook), en gros, chaque hook sera invoqué jusqu'à ce que l'un d'entre eux renvoie apache2.OK. Si un hook n'effectuer pas la traduction, il doit juste renvoyer apache2.DECLINED. Si le traitement de la requête doit être interrompu, la valeur renvoyée doit être apache2.DONE.
Exemple :
# httpd.conf LuaHookTranslateName /scripts/conf/hooks.lua silly_mapper
-- /scripts/conf/hooks.lua -- require "apache2" function silly_mapper(r) if r.uri == "/" then r.filename = "/var/www/home.lua" return apache2.OK else return apache2.DECLINED end end
Cette directive ne peut être
utilisée ni à l'intérieur d'une section <Directory>
ou <Files>
, ni dans un fichier htaccess.
Les arguments optionnels "early" ou "late" permettent de contrôler le moment auquel ce script s'exécute par rapport aux autres modules.
Description: | Fournit un point d'entrée pour la phase type_checker du traitement de la requête |
---|---|
Syntaxe: | LuaHookTypeChecker /chemin/vers/lua/script.lua hook_function_name |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | All |
Statut: | Expérimental |
Module: | mod_lua |
...
Description: | Contrôle la manière dont les sections de configuration parentes sont fusionnées dans les enfants |
---|---|
Syntaxe: | LuaInherit none|parent-first|parent-last |
Défaut: | LuaInherit parent-first |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | All |
Statut: | Expérimental |
Module: | mod_lua |
Compatibilité: | Versions 2.4.0 et supérieures |
Par défaut, si des directives LuaHook* se trouvent dans des sections de configuration Directory ou Location qui se chevauchent, les scripts définis dans les sections les plus spécifiques s'exécutent après ceux définis dans les sections plus génériques (LuaInherit parent-first). Vous pouvez inverser cet ordre, ou faire en sorte que le contexte parent ne s'applique pas du tout.
Jusqu'aux versions 2.3.x, le comportement par défaut consistait à ignorer les directives LuaHook* situées dans les sections de configuration parentes.
Description: | Provide a Lua function for content input filtering |
---|---|
Syntaxe: | LuaInputFilter filter_name /path/to/lua/script.lua function_name |
Contexte: | configuration du serveur |
Statut: | Expérimental |
Module: | mod_lua |
Compatibilité: | 2.5.0 and later |
La documentation de cette directive n'a pas encore t traduite. Veuillez vous reporter la version en langue anglaise.
Description: | Met en correspondance un chemin avec un gestionnaire lua |
---|---|
Syntaxe: | LuaMapHandler modele-uri /chemin/vers/lua/script.lua
[nom-fonction] |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | All |
Statut: | Expérimental |
Module: | mod_lua |
Cette directive permet de faire correspondre un modèle d'uri avec une fonction de gestionnaire située dans un fichier spécifique. Elle utilise les expressions rationnelles PCRE pour mettre en correspondance l'uri, et supporte les groupes de correspondance d'interpolation dans le chemin du fichier et le nom de la fonction. Prenez garde aux problèmes de sécurité en écrivant vos expressions rationnelles.
LuaMapHandler /(\w+)/(\w+) /scripts/$1.lua handle_$2
Cette directive va faire correspondre des uri comme /photos/show?id=9 au fichier /scripts/photos.lua, et invoquera la fonction de gestionnaire handle_show au niveau de la vm lua après chargement de ce fichier.
LuaMapHandler /bingo /scripts/wombat.lua
Cette directive invoquera la fonction "handle" qui est la valeur par défaut si aucun nom de fonction spécifique n'est spécifié.
Description: | Provide a Lua function for content output filtering |
---|---|
Syntaxe: | LuaOutputFilter filter_name /path/to/lua/script.lua function_name |
Contexte: | configuration du serveur |
Statut: | Expérimental |
Module: | mod_lua |
Compatibilité: | 2.5.0 and later |
La documentation de cette directive n'a pas encore t traduite. Veuillez vous reporter la version en langue anglaise.
Description: | Ajoute un répertoire au package.cpath de lua |
---|---|
Syntaxe: | LuaPackageCPath /chemin/vers/include/?.soa |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | All |
Statut: | Expérimental |
Module: | mod_lua |
Cette directive permet d'ajouter un chemin à la liste des chemins de recherche des bibliothèques partagées de lua. Ceci modifie le package.cpath dans les vms lua.
Description: | Ajoute un répertoire au package.path de lua |
---|---|
Syntaxe: | LuaPackagePath /chemin/vers/include/?.lua |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | All |
Statut: | Expérimental |
Module: | mod_lua |
Cette directive permet d'ajouter un chemin à la liste des chemins de recherche du module lua. Elle suit les mêmes conventions que lua. Ceci modifie le package.path dans les vms lua.
LuaPackagePath /scripts/lib/?.lua LuaPackagePath /scripts/lib/?/init.lua
Description: | Fournit un point d'entrée pour la gestion rapide du traitement de la requête |
---|---|
Syntaxe: | LuaQuickHandler /path/to/script.lua hook_function_name |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | All |
Statut: | Expérimental |
Module: | mod_lua |
Cette phase s'exécute juste après l'attribution de la requête à
un serveur virtuel, et permet d'effectuer certains traitements avant
le déroulement des autres phases, ou de servir une requête sans
avoir à la traduire, l'associer à un espace de stockage, etc...
Comme cette phase s'exécute avant toute autre, les directives telles
que <Location>
ou
<Directory>
ne
sont pas encore prises en compte, car Les URI n'ont pas encore été
entièrement interprétés.
Cette directive ne peut être
utilisée ni à l'intérieur d'une section <Directory>
ou <Files>
, ni dans un fichier htaccess.
Description: | Spécifie le chemin de base pour la résolution des chemins relatifs dans les directives de mod_lua |
---|---|
Syntaxe: | LuaRoot /chemin/vers/un/répertoire |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | All |
Statut: | Expérimental |
Module: | mod_lua |
Cette directive permet de spécifier le chemin de base qui sera utilisé pour évaluer tous les chemins relatifs dans mod_lua. En l'absence de cette directive, les chemins relatifs sont résolus par rapport au répertoire de travail courant, ce qui ne sera pas toujours approprié pour un serveur.
Description: | Une valeur parmi once, request, conn, thread -- la valeur par défaut est once |
---|---|
Syntaxe: | LuaScope once|request|conn|thread|server [min] [max] |
Défaut: | LuaScope once |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | All |
Statut: | Expérimental |
Module: | mod_lua |
Cette directive permet de spécifier la durée de vie de l'interpréteur Lua qui sera utilisé dans ce "répertoire". La valeur par défaut est "once".
min
et max
permettent
de spécifier les nombres minimaux et maximaux d'états lua à stocker
dans la liste.En général, les portées thread
et server
sont 2 à 3 fois plus rapides que les autres, car elles n'ont pas besoin
de régénérer de nouveaux états Lua à chaque requête (comme c'est le
cas avec le MPM event, où même les connexions persistantes utilisent un
nouveau thread pour chaque requête). Si vous pensez que vos scripts
n'auront pas de problème s'il réutilisent un état, alors les portées
thread
ou server
doivent être utilisées car
elles présenteront de meilleures performances. Alors que la portée
thread
fournira les réponses les plus rapides, la portée
server
utilisera moins de mémoire car les états sont
rassemblés dans des jeux, permettant par exemple à 1000 threads de
partager 100 états Lua, ne nécessitant ainsi que 10% de la mémoire
requise par la portée thread
.