<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision : 1174747 -->
+<!-- English Revision : 1180879 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
requête ; les expressions suivantes sont comparées à la sortie de
la dernière règle de réécriture qui a été appliquée.</p>
-<note><title>Qu'est-ce qui est comparé ?</title>
+<note><title><a id="what_is_matched" name="what_is_matched">Qu'est-ce qui est comparé ?</a></title>
<p>Dans un contexte de serveur virtuel <directive
module="core">VirtualHost</directive>, le <em>modèle</em> est tout
section de laquelle elles sont décrites. Ces trois types de
variables sont évaluées dans l'ordre ci-dessus.</p>
- <p>Comme mentionné précédemment, toutes les règles de
- réécriture sont appliquées à la chaîne de <em>Substitution</em>
- (selon l'ordre dans lequel elles sont définies dans le fichier
- de configuration). L'URL est <strong>intégralement
+ <p>Chaque règle de réécriture s'applique au résultat de la règle
+ précédente, selon l'ordre dans lequel elles ont été définies dans
+ le fichier de configuration. L'URI du chemin du fichier (voir
+ ci-dessus <a href="#what_is_matched">Qu'est-ce qui est
+ comparé ?</a>) est <strong>intégralement
remplacée</strong> par la chaîne de <em>Substitution</em> et le
processus de réécriture se poursuit jusqu'à ce que toutes les
règles aient été appliquées, ou qu'il soit explicitement stoppé
- par un drapeau <code><strong>L</strong></code>.</p>
+ par un drapeau <a
+ href="../rewrite/flags.html#flag_l"><code><strong>L</strong></code></a>,
+ ou par un autre drapeau qui implique un arrêt immédiat, comme
+ <code><strong>END</strong></code> ou
+ <code><strong>F</strong></code>.</p>
<note><title>Modifier la chaîne de requête</title>
<p>Par défaut, la chaîne de requête est transmise sans
<?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 : 1174747 -->
+<!-- English Revision : 1180985 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<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="Internal"><title>Fonctionnement interne</title>
-
- <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>
-</section>
-
<section id="InternalAPI"><title>Phases de l'API</title>
- <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
- une manipulation URL/nom de fichier dans un contexte de
- 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>
+ <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 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 <directive module="mod_rewrite">RewriteBase</directive>
+ 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 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>
projects / apache / commitdiff