Structure d'un module
Ce paragraphe décrit les éléments qui composent un module d'Apache. Une table de commandes, qui sont utilisées dans le fichier de configuration. Chaque ligne de la table contient le nom de la commande et le nom de la fonction associée à cette commande. Cette table peut être vide si le module n'implémente aucune commande de configuration. Une table d'handlers, utilisés pour l'étape de réponse dans le traitement d'une requête. Chaque module intervenant dans l'étape de réponse peut implémenter un ou plusieurs handlers. Chaque ligne de la table contient le nom de l'handler et la fonction associée. Si le module n'intervient pas dans la réponse, cette table est vide. Pour cette étape les modules déclarent une table d'handlers car ils peuvent prendre en charge plusieurs types de fichiers (donc ils ont besoin d'une ligne de table par type de fichier). Cependant la plupart des modules ne déclarent q'un seul handler dans cette table. Les handlers correspondant aux autres étapes du traitement d'une requête (un handler par étape). Pour les étapes où le module n'intervient pas, les handlers correspondants ont la valeur NULL.
Traitement de la requête
Au lancement d'Apache, un tableau répertoriant pour chaque étape (sauf l'étape de réponse) tous les handlers traitant cette étape est créé, en parcourant la configuration de chaque module dans l'ordre inverse où ils ont été activés dans le fichier de configuration (le module activé en dernier a la plus grande priorité). Pour chaque étape de traitement, le serveur possède donc une liste d'handlers (ainsi que le module où est implémenté l'handler). Un handler peut typiquement exécuter l'une des trois procédures suivantes : Traiter la requête (Handle), et indiquer ce fait en renvoyant la constante OK. Rejeter la requête (Decline) c'est à dire refuser de la traiter, en retournant la constante DECLINED. Dans ce cas, le serveur se comporte comme si le handler était tout simplement inexistant. Signaler une erreur, en renvoyant l'un des codes d'erreur HTTP. Ceci provoque la fin du traitement normal de la requête, bien qu'une fonction ErrorDocument puisse être invoquée pour essayer de résoudre l'erreur, laquelle sera dans tous les cas enregistrée dans les fichiers de logs. Après invocation du premier handler, la plupart des étapes sont achevées si l'handler a retourné OK. Si le premier handler retourne DECLINED, l'handler suivant est invoqué et ainsi de suite jusqu'à obtenir la constante OK. Pour les étapes d'authentification, les " fixups ", et la phase d'enregistrement dans le fichier de log, tous les handlers associés sont appelés dans tous les cas (sauf si un handler retourne une erreur qui interrompt le traitement). L'étape " fixups " est effectuée juste avant l'étape de réponse. Elle permet aux modules qui implémente un handler pour une phase donnée, mais qui n'ont pas pu traiter cette étape car l'handler d'un autre module a retourné OK avant pour cette étape, de modifier certains champs de la réponse. Pour l'étape fournissant la réponse, un handler est associé à la requête selon le type MIME de l'objet requis. Par conséquent, la réponse sera fournie uniquement par le module qui implémente cet handler. Pour les requêtes n'ayant pas d'handler de réponse associé (le type de fichier requis ne nécessite pas de traitement particulier), l'handler par défaut du module noyau (core) d'Apache est invoqué pour fournir la réponse au client. Les étapes décrites précédemment sont nommées dans les sources d'Apache comme suit (excepté la phase que j'ai appelée " réponse " qui correspond à l'invocation de l'handler chargé d'émettre la réponse au client) : filename translation header parser check access check user_id check auth type checker fixups réponse logger Ce sont ces noms que j'utilise dans la description des modules d'Apache. Contact - English version
