tech.html.fr revision 255e0e7a96ad3f76da14e128959735178115fb23
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
This file is generated from xml source: DO NOT EDIT
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-->
<title>D�tails techniques sur le module Apache mod_rewrite - Serveur Apache HTTP</title>
<link href="/style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
<link href="/style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
<body id="manual-page"><div id="page-header">
<p class="menu"><a href="/mod/">Modules</a> | <a href="/mod/directives.html">Directives</a> | <a href="/faq/">FAQ</a> | <a href="/glossary.html">Glossaire</a> | <a href="/sitemap.html">Plan du site</a></p>
<p class="apache">Serveur Apache HTTP Version 2.3</p>
<div id="path">
<a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">Serveur HTTP</a> > <a href="http://httpd.apache.org/docs/">Documentation</a> > <a href="../">Version 2.3</a> > <a href="./">Rewrite</a></div><div id="page-content"><div id="preamble"><h1>D�tails techniques sur le module Apache mod_rewrite</h1>
<div class="toplang">
<p><span>Langues Disponibles: </span><a href="/en/rewrite/tech.html" hreflang="en" rel="alternate" title="English"> en </a> |
</div>
<p>Ce document passe en revue certains d�tails techniques � propos du
module mod_rewrite et de la mise en correspondance des URLs</p>
</div>
<div id="quickview"><ul id="toc"><li><img alt="" src="/images/down.gif" /> <a href="#Internal">Fonctionnement interne</a></li>
<li><img alt="" src="/images/down.gif" /> <a href="#InternalRuleset">Traitement du jeu de r�gles</a></li>
</ul><h3>Voir aussi</h3><ul class="seealso"><li><a href="/mod/mod_rewrite.html">Documentation du module</a></li><li><a href="intro.html">Introduction � mod_rewrite</a></li><li><a href="rewrite_guide.html">Guide de r��criture - exemples
avanc�e - exemples utiles avanc�s</a></li></ul></div>
<div class="section">
<h2><a name="Internal" id="Internal">Fonctionnement interne</a></h2>
<p>Le fonctionnement interne de ce module est tr�s complexe, mais
il est n�cessaire de l'expliquer, m�me � l'utilisateur "standard",
afin d'�viter les erreurs courantes et de pouvoir exploiter toutes
ses fonctionnalit�s.</p>
<div class="section">
<h2><a name="InternalAPI" id="InternalAPI">Phases de l'API</a></h2>
<p>Il faut tout d'abord bien comprendre que le traitement d'une
requ�te HTTP par Apache s'effectue en plusieurs phases. L'API
d'Apache fournit un point d'accroche (hook) pour chacune de ces
phases. Mod_rewrite utilise deux de ces hooks : le hook de
conversion des URLs en noms de fichiers qui est utilis� quand la
requ�te HTTP a �t� lue mais avant le d�marrage de tout processus
d'autorisation, et le hook "Fixup" qui est d�clench� apr�s les
phases d'autorisation et apr�s la lecture des fichiers de
configuration niveau r�pertoire (<code>.htaccess</code>), mais
avant que le gestionnaire de contenu soit activ�.</p>
<p>Donc, lorsqu'une requ�te arrive et quand Apache a d�termin� le
serveur correspondant (ou le serveur virtuel), le moteur de
r��criture commence le traitement de toutes les directives de
mod_rewrite de la configuration du serveur principal dans la phase
de conversion URL vers nom de fichier. Une fois ces �tapes
franchies, lorsque les repertoires de donn�es finaux ont �t�
trouv�s, les directives de configuration de mod_rewrite au niveau
r�pertoire sont �x�cut�es dans la phase Fixup. Dans les deux cas,
mod_rewrite r��crit les URLs soit en nouvelles URLs, soit en noms
de fichiers, bien que la distinction entre les deux ne soit pas
�vidente. Cette utilisation de l'API n'�tait pas sens�e s'op�rer
de cette mani�re lorsque l'API fut con�ue, mais depuis Apache 1.x,
c'est le seul mode op�ratoire possible pour mod_rewrite. Afin de
rendre les choses plus claires, souvenez-vous de ces deux points :</p>
<ol>
<li>Bien que mod_rewrite r��crive les URLs en URLs, les URLs en
noms de fichiers et m�me des noms de fichiers en d'autres noms
de fichiers, l'API ne propose actuellement qu'un hook URL vers
nom de fichier. Les deux hooks manquants seront ajout�s dans
Apache � partir de la version 2.0 afin de rendre le processus
plus clair. Mais ce point ne pr�sente pas d'inconv�nient pour
l'utilisateur, il s'agit simplement d'un fait que vous devez
garder � l'esprit : Apache en fait plus avec le hook URL vers
nom de fichier que l'API n'a la pr�tention d'en faire.</li>
<li>
Paradoxalement, mod_rewrite permet la manipulation d'URLs dans
un contexte de r�pertoire, <em>c'est � dire</em> dans les
fichiers <code>.htaccess</code>, bien que ces derniers
soient trait�s bien longtemps apr�s que les URLs n'aient �t�
traduites en noms de fichiers. Les choses doivent se d�rouler
ainsi car les fichiers <code>.htaccess</code> r�sident dans le
syst�me de fichiers, et le traitement a d�j� atteint
cette �tape. Autrement dit, en accord avec les phases de
l'API, � ce point du traitement, il est trop tard pour
effectuer des manipulations d'URLs. Pour r�soudre ce probl�me
d'ant�riorit�, mod_rewrite utilise une astuce : pour effectuer
r�pertoire, mod_rewrite r��crit tout d'abord le nom de fichier
en son URL d'origine (ce qui est normalement impossible, mais
voir ci-dessous l'astuce utilis�e par la directive
<code>RewriteBase</code> pour y parvenir), puis
initialise une nouvelle sous-requ�te interne avec la nouvelle
URL ; ce qui a pour effet de red�marrer le processus des
phases de l'API.
<p>Encore une fois, mod_rewrite fait tout ce qui est en son
pouvoir pour rendre la complexit� de cette �tape compl�tement
transparente � l'utilisateur, mais vous devez garder ceci �
l'esprit : alors que les manipulations d'URLs dans le contexte
du serveur sont vraiment rapides et efficaces, les r��critures
dans un contexte de r�pertoire sont lentes et inefficaces �
cause du probl�me d'ant�riorit� pr�cit�. Cependant, c'est la
seule mani�re dont mod_rewrite peut proposer des manipulations
d'URLs (limit�es � une branche du syst�me de fichiers) �
l'utilisateur standard.</p>
</li>
</ol>
<p>Ne perdez pas de vue ces deux points!</p>
<div class="section">
<h2><a name="InternalRuleset" id="InternalRuleset">Traitement du jeu de r�gles</a></h2>
<p>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.</p>
<p>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 <code class="directive"><a href="/mod/mod_rewrite.html#rewriterule">RewriteRule</a></code>) les unes
� la suite des autres, et lorsqu'une r�gle s'applique, il parcourt
les �ventuelles conditions (directives
<code>RewriteCond</code>directives) 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.</p>
<p class="figure">
<img src="/images/mod_rewrite_fig1.gif" width="428" height="385" alt="[N�cessite le mode graphique pour l'affichage]" /><br />
<dfn>Figure 1:</dfn>D�roulement du contr�le � travers le jeu de
r�gles de r��criture
</p>
<p>Comme vous pouvez le voir, l'URL est tout d'abord compar�e au
<em>Mod�le</em> 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
<em>Mod�le</em>, mod_rewrite recherche la pr�sence de conditions
correspondantes. S'il n'y en a pas, mod_rewrite remplace
simplement l'URL par une cha�ne �labor�e � partir de la cha�ne de
<em>Substitution</em>, 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 <em>TestString</em> 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 <em>CondPattern</em>. 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 <em>Substitution</em>.</p>
</div></div>
<div class="bottomlang">
<p><span>Langues Disponibles: </span><a href="/en/rewrite/rewrite_tech.html" hreflang="en" rel="alternate" title="English"> en </a> |
</div><div id="footer">
<p class="apache">Copyright 2009 The Apache Software Foundation.<br />Autoris� sous <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
<p class="menu"><a href="/mod/">Modules</a> | <a href="/mod/directives.html">Directives</a> | <a href="/faq/">FAQ</a> | <a href="/glossary.html">Glossaire</a> | <a href="/sitemap.html">Plan du site</a></p></div>
</body></html>