From: Lucien Gentis 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.
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 +ou la définition de types MIME :
+ +| Phase d'accroche | +Directive mod_lua | +Description | +
|---|---|---|
| Gestionnaire rapide | +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 | +Cette phase traduit l'URI de la requête en nom de fichier
+ sur le système. Ce sont des modules comme
+ |
+ |
| Choix du lieu de stockage de la ressource | +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 | +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 | +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 | +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 | +Cette phase assigne un type de contenu et un gestionnaire à + la ressource. | +|
| Derniers réglages | +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 |
+ 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.
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 + 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 |
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 :
+Les autres codes d'état HTTP ne sont pas encore implémentés.
@@ -516,9 +776,9 @@ relatifs dans les directives de mod_luamin 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.
+
...
Identique à la directive
+
...
+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
Cette directive ne peut être
utilisée ni à l'intérieur d'une section Lorsqu'une fonction lua a été enregistrée en tant que fournisseur
d'autorisation, elle peut être appelée via la directive