D�tails techniques sur le module Apache mod_rewrite

Phases de l'API

Le traitement des requ�tes par le serveur HTTP Apache se d�roule en plusieurs phases. Au cours de chaque phase, un ou plusieurs modules peuvent �tre appel�s pour traiter la partie concern�e du cycle de vie de la requ�te. Les diff�rentes phases peuvent consister en traduction d'URL en nom de fichier, authentification, autorisation, gestion de contenu ou journalisation (la liste n'est pas exhaustive).

mod_rewrite agit dans deux de ces phases (ou accroches - hooks - comme on les nomme souvent) pour la r��criture des URLs.

Tout d'abord, il utilise le hook traduction URL vers nom de fichier qui intervient apr�s la lecture de la requ�te HTTP, mais avant le processus d'autorisation. Ensuite, il utilise le hook Fixup, qui intervient apr�s les phases d'autorisation, apr�s la lecture des fichiers de configuration de niveau r�pertoire (fichiers .htaccess), mais avant l'appel du gestionnaire de contenu.

Ainsi, lorsqu'une requ�te arrive et une fois le serveur correspondant ou le serveur virtuel d�termin�, le moteur de r��criture commence � traiter toute directive apparaissant dans la configuration de niveau serveur (autrement dit dans le fichier de configuration principal du serveur et les sections <Virtualhost>). Tout ce processus s'ex�cute au cours de la phase de traduction URL vers nom de fichier.

Quelques �tapes plus loin, une fois les r�pertoires de donn�es finaux trouv�s, les directives de configuration de niveau r�pertoire (fichiers .htaccess et sections <Directory>) sont appliqu�es. Ce processus s'ex�cute au cours de la phase Fixup.

Dans tous ces cas, mod_rewrite r��crit le REQUEST_URI soit vers une nouvelle URL, soit vers un nom de fichier.

Dans un contexte de niveau r�pertoire (autrement dit dans les fichiers .htaccess et les sections Directory), les r�gles de r��criture s'appliquent apr�s la traduction de l'URL en nom de fichier. C'est pourquoi le chemin URL auquel mod_rewrite compare initialement les directives RewriteRule est le chemin complet vers le nom de fichier traduit amput� de la partie r�pertoires (y compris le dernier slash).

Un exemple : si les r�gles se trouvent dans /var/www/foo/.htaccess et si une requ�te pour /foo/bar/baz est trait�, une expression comme ^bar/baz$ correspondra.

Si une substitution intervient dans un contexte de r�pertoire, une nouvelle sous-requ�te interne est g�n�r�e avec la nouvelle URL, ce qui relance le traitement des phases de la requ�te. Si la substitution est un chemin relatif, la directive RewriteBase d�termine le chemin URL devant pr�fixer cette substitution. Dans un contexte de r�pertoire, il faut s'assurer de cr�er des r�gles qui n'effectueront pas de substitution au cours d'une passe ult�rieure du processus de r��criture au niveau r�pertoire afin d'�viter les bouclages . Voir Bouclage dans le processus de r��criture pour une discussion plus d�taill�e � propos de ce probl�me.

En cons�quence de cette manipulation de l'URL , vous devrez pensez � confectionner diff�remment vos r�gles de r��criture dans un contexte de niveau r�pertoire. En particulier, rappelez-vous que le chemin de r�pertoire sera absent de l'URL que vos r�gles de r��criture verront. Voici quelques exemples qui permettront de clarifier les choses :

Pour une �tude plus approfondie de la mani�re dont mod_rewrite manipule les URLs dans les diff�rents contextes, vous pouvez consulter les entr�es du journal g�n�r�es au cours du processus de r��criture.

Traitement du jeu de r�gles

Maintenant, quand mod_rewrite se lance dans ces deux phases de l'API, il lit le jeu de r�gles configur�es depuis la structure contenant sa configuration (qui a �t� elle-m�me cr��e soit au d�marrage d'Apache pour le contexte du serveur, soit lors du parcours des r�pertoires par le noyau d'Apache pour le contexte de r�pertoire). Puis le moteur de r��criture est d�marr� avec le jeu de r�gles contenu (une ou plusieurs r�gles associ�es � leurs conditions). En lui-m�me, le mode op�ratoire du moteur de r��criture d'URLs est exactement le m�me dans les deux contextes de configuration. Seul le traitement du r�sultat final diff�re.

L'ordre dans lequel les r�gles sont d�finies est important car le moteur de r��criture les traite selon une chronologie particuli�re (et pas tr�s �vidente). Le principe est le suivant : le moteur de r��criture traite les r�gles (les directives RewriteRule) les unes � la suite des autres, et lorsqu'une r�gle s'applique, il parcourt les �ventuelles conditions (directives RewriteConddirectives) associ�es. Pour des raisons historiques, les conditions pr�c�dent les r�gles, si bien que le d�roulement du contr�le est un peu compliqu�. Voir la figure 1 pour plus de d�tails.

Figure 1:D�roulement du contr�le � travers le jeu de r�gles de r��criture

L'URL est tout d'abord compar�e au Mod�le de chaque r�gle. Lorsqu'une r�gle ne s'applique pas, mod_rewrite stoppe imm�diatement le traitement de cette r�gle et passe � la r�gle suivante. Si l'URL correspond au Mod�le, mod_rewrite recherche la pr�sence de conditions correspondantes (les directives Rewritecond apparaissant dans la configuration juste avant les r�gles de r��criture). S'il n'y en a pas, mod_rewrite remplace l'URL par une cha�ne �labor�e � partir de la cha�ne de Substitution, puis passe � la r�gle suivante. Si des conditions sont pr�sentes, mod_rewrite lance un bouclage secondaire afin de les traiter selon l'ordre dans lequel elles sont d�finies. La logique de traitement des conditions est diff�rente : on ne compare pas l'URL � un mod�le. Une cha�ne de test TestString est tout d'abord �labor�e en d�veloppant des variables, des r�f�rences arri�res, des recherches dans des tables de correspondances, etc..., puis cette cha�ne de test est compar�e au mod�le de condition CondPattern. Si le mod�le ne correspond pas, les autres conditions du jeu ne sont pas examin�es et la r�gle correspondante ne s'applique pas. Si le mod�le correspond, la condition suivante est examin�e et ainsi de suite jusqu'� la derni�re condition. Si toutes les conditions sont satisfaites, le traitement de la r�gle en cours se poursuit avec le remplacement de l'URL par la cha�ne de Substitution.