1 <?xml version="1.0" encoding="ISO-8859-1" ?>
2 <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
3 <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
4 <!-- English Revision: 1673945 -->
5 <!-- French translation : Lucien GENTIS -->
6 <!-- Reviewed by : Vincent Deffontaines -->
9 Licensed to the Apache Software Foundation (ASF) under one or more
10 contributor license agreements. See the NOTICE file distributed with
11 this work for additional information regarding copyright ownership.
12 The ASF licenses this file to You under the Apache License, Version 2.0
13 (the "License"); you may not use this file except in compliance with
14 the License. You may obtain a copy of the License at
16 http://www.apache.org/licenses/LICENSE-2.0
18 Unless required by applicable law or agreed to in writing, software
19 distributed under the License is distributed on an "AS IS" BASIS,
20 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
21 See the License for the specific language governing permissions and
22 limitations under the License.
25 <manualpage metafile="tech.xml.meta">
26 <parentdocument href="./">Rewrite</parentdocument>
28 <title>Détails techniques sur le module Apache mod_rewrite</title>
31 <p>Ce document passe en revue certains détails techniques à propos du
32 module mod_rewrite et de la mise en correspondance des URLs</p>
34 <seealso><a href="../mod/mod_rewrite.html">Documentation du module mod_rewrite</a></seealso>
35 <seealso><a href="intro.html">Introduction à mod_rewrite</a></seealso>
36 <seealso><a href="remapping.html">Redirection et remise en
37 correspondance</a></seealso>
38 <seealso><a href="access.html">Contrôle d'accès</a></seealso>
39 <seealso><a href="vhosts.html">Serveurs virtuels</a></seealso>
40 <seealso><a href="proxy.html">Mise en cache</a></seealso>
41 <seealso><a href="rewritemap.html">Utilisation de RewriteMap</a></seealso>
42 <seealso><a href="advanced.html">Techniques avancées</a></seealso>
43 <seealso><a href="avoid.html">Quand ne pas utiliser mod_rewrite</a></seealso>
45 <section id="InternalAPI"><title>Phases de l'API</title>
47 <p>Le traitement des requêtes par le serveur HTTP Apache se
48 déroule en plusieurs phases. Au cours de chaque phase, un ou
49 plusieurs modules peuvent être appelés pour traiter la partie
50 concernée du cycle de vie de la requête. Les différentes phases
51 peuvent consister en traduction d'URL en nom de fichier,
52 authentification, autorisation, gestion de contenu ou journalisation (la
53 liste n'est pas exhaustive).</p>
55 <p>mod_rewrite agit dans deux de ces phases (ou accroches - hooks -
56 comme on les nomme souvent) pour la réécriture des URLs.</p>
58 <p>Tout d'abord, il utilise le hook traduction URL vers nom de
59 fichier qui intervient après la lecture de la requête HTTP, mais
60 avant le processus d'autorisation. Ensuite, il utilise le hook
61 Fixup, qui intervient après les phases d'autorisation, après la
62 lecture des fichiers de configuration de niveau répertoire (fichiers
63 <code>.htaccess</code>), mais avant l'appel du gestionnaire de
66 <p>Lorsqu'une requête arrive et une fois le serveur
67 correspondant ou le serveur virtuel déterminé, le moteur de
68 réécriture commence à traiter toute directive apparaissant dans la
69 configuration de niveau serveur (autrement dit dans le
70 fichier de configuration principal du serveur et les sections
71 <directive module="core" type="section">Virtualhost</directive>).
72 Tout ce processus s'exécute au cours de la phase de traduction URL
73 vers nom de fichier.</p>
75 <p>Quelques étapes plus loin, une fois les répertoires de données
76 finaux trouvés, les directives de configuration de niveau répertoire
77 (fichiers <code>.htaccess</code> et sections <directive module="core"
78 type="section">Directory</directive>) sont appliquées. Ce processus
79 s'exécute au cours de la phase Fixup.</p>
81 <p>Dans tous ces cas, mod_rewrite réécrit le
82 <code>REQUEST_URI</code> soit vers une nouvelle URL, soit vers un
85 <p>Dans un contexte de niveau répertoire (autrement dit dans les
86 fichiers <code>.htaccess</code> et les sections
87 <code>Directory</code>), les règles de réécriture s'appliquent après
88 la traduction de l'URL en nom de fichier. C'est pourquoi le chemin
89 URL auquel mod_rewrite compare initialement les directives
90 <directive module="mod_rewrite">RewriteRule</directive> est le
91 chemin complet vers le nom de fichier traduit amputé de la partie
92 répertoires (y compris le dernier slash).</p>
94 <p>Un exemple : si les règles se trouvent dans
95 /var/www/foo/.htaccess et si une requête pour /foo/bar/baz est
96 traité, une expression comme ^bar/baz$ correspondra.</p>
98 <p>Si une substitution intervient dans un contexte de répertoire,
99 une nouvelle sous-requête interne est générée avec la nouvelle URL,
100 ce qui relance le traitement des phases de la requête. Si la
101 substitution est un chemin relatif, la directive <directive
102 module="mod_rewrite">RewriteBase</directive> détermine le chemin URL
103 devant préfixer cette substitution. Dans un contexte de répertoire,
104 il faut s'assurer de créer des règles qui
105 n'effectueront pas de substitution au
106 cours d'une passe ultérieure du processus de réécriture au niveau
107 répertoire afin d'éviter les bouclages . Voir <a
108 href="http://wiki.apache.org/httpd/RewriteLooping">Bouclage dans le
109 processus de réécriture</a> pour une discussion plus détaillée à
110 propos de ce problème.</p>
112 <p>En conséquence de cette manipulation de l'URL , vous devrez
113 pensez à confectionner différemment vos règles de réécriture dans un
114 contexte de niveau répertoire. En particulier, rappelez-vous que le
115 chemin de répertoire sera absent de l'URL que vos règles de
116 réécriture verront. Voici quelques exemples qui permettront de
117 clarifier les choses :</p>
122 <th>Position de la règle</th>
123 <th>Règle</th>
127 <td>Section VirtualHost</td>
128 <td>RewriteRule "^/images/(.+)\.jpg" "/images/$1.gif"</td>
132 <td>Fichier .htaccess à la racine des documents</td>
133 <td>RewriteRule "^images/(.+)\.jpg" "images/$1.gif"</td>
137 <td>Fichier .htaccess dans le répertoire images</td>
138 <td>RewriteRule "^(.+)\.jpg" "$1.gif"</td>
143 <p>Pour une étude plus approfondie de la manière dont mod_rewrite
144 manipule les URLs dans les différents contextes, vous pouvez
145 consulter les <a href="../mod/mod_rewrite.html#logging">entrées du
146 journal</a> générées au cours du processus de réécriture.</p>
150 <section id="InternalRuleset"><title>Traitement du jeu de règles</title>
152 <p>Maintenant, quand mod_rewrite se lance dans ces deux phases de
153 l'API, il lit le jeu de règles configurées depuis la structure
154 contenant sa configuration (qui a été elle-même créée soit au
155 démarrage d'Apache pour le contexte du serveur, soit lors du
156 parcours des répertoires par le noyau d'Apache pour le contexte de
157 répertoire). Puis le moteur de réécriture est démarré avec le jeu
158 de règles contenu (une ou plusieurs règles associées à leurs
159 conditions). En lui-même, le mode opératoire du moteur de
160 réécriture d'URLs est exactement le même dans les deux contextes
161 de configuration. Seul le traitement du résultat final diffère.</p>
163 <p>L'ordre dans lequel les règles sont définies est important car
164 le moteur de réécriture les traite selon une chronologie
165 particulière (et pas très évidente). Le principe est le suivant :
166 le moteur de réécriture traite les règles (les directives <directive
167 module="mod_rewrite">RewriteRule</directive>) les unes
168 à la suite des autres, et lorsqu'une règle s'applique, il parcourt
169 les éventuelles conditions (directives
170 <code>RewriteCond</code>directives) associées.
171 Pour des raisons historiques, les
172 conditions précèdent les règles, si bien que le déroulement du
173 contrôle est un peu compliqué. Voir la figure 1 pour plus de
176 <img src="../images/rewrite_process_uri.png"
177 alt="Flux des comparaisons des directives RewriteRule et RewriteCond" /><br />
178 <dfn>Figure 1:</dfn>Déroulement du contrôle à travers le jeu de
179 règles de réécriture
181 <p>L'URL est tout d'abord comparée au
182 <em>Modèle</em> de chaque règle. Lorsqu'une règle ne s'applique
183 pas, mod_rewrite stoppe immédiatement le traitement de cette règle
184 et passe à la règle suivante. Si l'URL correspond au
185 <em>Modèle</em>, mod_rewrite recherche la présence de conditions
186 correspondantes (les directives Rewritecond apparaissant dans la
188 avant les règles de réécriture). S'il n'y en a pas, mod_rewrite remplace
189 l'URL par une chaîne élaborée à partir de la chaîne de
190 <em>Substitution</em>, puis passe à la règle suivante. Si des
191 conditions sont présentes, mod_rewrite lance un bouclage
192 secondaire afin de les traiter selon l'ordre dans lequel elles
193 sont définies. La logique de traitement des conditions est
194 différente : on ne compare pas l'URL à un modèle. Une chaîne de
195 test <em>TestString</em> est tout d'abord élaborée en développant
196 des variables, des références arrières, des recherches dans des
197 tables de correspondances, etc..., puis cette chaîne de test est
198 comparée au modèle de condition <em>CondPattern</em>. Si le modèle
199 ne correspond pas, les autres conditions du jeu ne sont pas
200 examinées et la règle correspondante ne s'applique pas. Si le
201 modèle correspond, la condition suivante est examinée et ainsi de
202 suite jusqu'à la dernière condition. Si toutes les conditions sont
203 satisfaites, le traitement de la règle en cours se poursuit avec
204 le remplacement de l'URL par la chaîne de <em>Substitution</em>.</p>
projects / apache / blob