1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
|
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
<!-- English Revision : 1325527 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<manualpage metafile="tech.xml.meta">
<parentdocument href="./">Rewrite</parentdocument>
<title>Détails techniques sur le module Apache mod_rewrite</title>
<summary>
<p>Ce document passe en revue certains détails techniques à propos du
module mod_rewrite et de la mise en correspondance des URLs</p>
</summary>
<seealso><a href="../mod/mod_rewrite.html">Documentation du module mod_rewrite</a></seealso>
<seealso><a href="intro.html">Introduction à mod_rewrite</a></seealso>
<seealso><a href="remapping.html">Redirection et remise en
correspondance</a></seealso>
<seealso><a href="access.html">Contrôle d'accès</a></seealso>
<seealso><a href="vhosts.html">Serveurs virtuels</a></seealso>
<seealso><a href="proxy.html">Mise en cache</a></seealso>
<seealso><a href="rewritemap.html">Utilisation de RewriteMap</a></seealso>
<seealso><a href="advanced.html">Techniques avancées</a></seealso>
<seealso><a href="avoid.html">Quand ne pas utiliser mod_rewrite</a></seealso>
<section id="InternalAPI"><title>Phases de l'API</title>
<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
<directive module="core" type="section">Virtualhost</directive>).
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 <directive module="core"
type="section">Directory</directive>) 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 le chemin
URL auquel mod_rewrite compare initialement les directives
<directive module="mod_rewrite">RewriteRule</directive> est le
chemin complet vers le nom de fichier traduit amputé de la partie
répertoires (y compris le dernier slash).</p>
<p>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.</p>
<p>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 <directive
module="mod_rewrite">RewriteBase</directive> 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 <a
href="http://wiki.apache.org/httpd/RewriteLooping">Bouclage dans le
processus de réécriture</a> pour une discussion plus détaillée à
propos de ce problème.</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 border="1">
<tr>
<th>Position de la règle</th>
<th>Règle</th>
</tr>
<tr>
<td>Section VirtualHost</td>
<td>RewriteRule ^/images/(.+)\.jpg /images/$1.gif</td>
</tr>
<tr>
<td>Fichier .htaccess à la racine des documents</td>
<td>RewriteRule ^images/(.+)\.jpg images/$1.gif</td>
</tr>
<tr>
<td>Fichier .htaccess dans le répertoire images</td>
<td>RewriteRule ^(.+)\.jpg $1.gif</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>
</section>
<section id="InternalRuleset"><title>Traitement du jeu de règles</title>
<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 <directive
module="mod_rewrite">RewriteRule</directive>) 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_process_uri.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>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 (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
<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>
</section>
</manualpage>
|
