tech.html.fr revision f086b4b402fa9a2fefc7dda85de2a3cc1cd0a654
<?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="#InternalAPI">Phases de l'API</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 mod_rewrite</a></li><li><a href="intro.html">Introduction � mod_rewrite</a></li><li><a href="remapping.html">Redirection et remise en
correspondance</a></li><li><a href="access.html">Contr�le d'acc�s</a></li><li><a href="vhosts.html">Serveurs virtuels</a></li><li><a href="proxy.html">Mise en cache</a></li><li><a href="rewritemap.html">Utilisation de RewriteMap</a></li><li><a href="advanced.html">Techniques avanc�es</a></li><li><a href="avoid.html">Quand ne pas utiliser mod_rewrite</a></li></ul></div>
<div class="section">
<h2><a name="InternalAPI" id="InternalAPI">Phases de l'API</a></h2>
<p>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).</p>
<p>mod_rewrite agit dans deux de ces phases (ou accroches - hooks -
comme on les nomme souvent) pour la r��criture des URLs.</p>
<p>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
<code>.htaccess</code>), mais avant l'appel du gestionnaire de
contenu.</p>
<p>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
Tout ce processus s'ex�cute au cours de la phase de traduction URL
vers nom de fichier.</p>
<p>Quelques �tapes plus loin, une fois les r�pertoires de donn�es
finaux trouv�s, les directives de configuration de niveau r�pertoire
(fichiers <code>.htaccess</code> et sections <code class="directive"><a href="/mod/core.html#directory"><Directory></a></code>) sont appliqu�es. Ce processus
s'ex�cute au cours de la phase Fixup.</p>
<p>Dans tous ces cas, mod_rewrite r��crit le
<code>REQUEST_URI</code> soit vers une nouvelle URL, soit vers un
nom de fichier.</p>
<p>Dans un contexte de niveau r�pertoire (autrement dit dans les
fichiers <code>.htaccess</code> et les sections
<code>Directory</code>), les r�gles de r��criture s'appliquent apr�s
la traduction de l'URL en nom de fichier. C'est pourquoi mod_rewrite
retraduit temporairement le nom de fichier en URL en supprimant le
chemin de r�pertoire avant d'appliquer les r�gles (Reportez-vous �
la directive <code class="directive"><a href="/mod/mod_rewrite.html#rewritebase">RewriteBase</a></code>
pour voir comment vous pourrez par la suite personnaliser la mani�re
dont tout ceci est trait�). Ensuite, une nouvelle sous-requ�te
interne est initi�e avec la nouvelle URL, ce qui red�marre le
traitement des phases de l'API.</p>
<p>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 :</p>
<table class="bordered">
<tr>
<th>Position de la r�gle</th>
<th>R�gle</th>
</tr>
<tr>
<td>Section VirtualHost</td>
</tr>
<tr>
<td>Fichier .htaccess � la racine des documents</td>
</tr>
<tr>
<td>Fichier .htaccess dans le r�pertoire images</td>
</tr>
</table>
<p>Pour une �tude plus approfondie de la mani�re dont mod_rewrite
manipule les URLs dans les diff�rents contextes, vous pouvez
consulter les <a href="/mod/mod_rewrite.html#logging">entr�es du
journal</a> g�n�r�es au cours du processus de r��criture.</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/rewrite_rule_flow.png" alt="Flux des comparaisons des directives RewriteRule et RewriteCond" /><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/tech.html" hreflang="en" rel="alternate" title="English"> en </a> |
</div><div id="footer">
<p class="apache">Copyright 2011 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>