diff options
| author | Lucien Gentis <lgentis@apache.org> | 2011-10-15 18:39:18 +0200 |
|---|---|---|
| committer | Lucien Gentis <lgentis@apache.org> | 2011-10-15 18:39:18 +0200 |
| commit | 8ee73a5b63989e8e4e995daf3f14e93c6f78c953 (patch) | |
| tree | e3d28fc7406856bc24dc629aca696d04c929c374 /docs/manual/rewrite | |
| parent | There is absolutely no reason to have two 4k-sized constant strmatch patterns (diff) | |
| download | apache2-8ee73a5b63989e8e4e995daf3f14e93c6f78c953.tar.xz apache2-8ee73a5b63989e8e4e995daf3f14e93c6f78c953.zip | |
Updates.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1183669 13f79535-47bb-0310-9956-ffa450edef68
Diffstat (limited to 'docs/manual/rewrite')
| -rw-r--r-- | docs/manual/rewrite/tech.xml.fr | 168 |
1 files changed, 87 insertions, 81 deletions
diff --git a/docs/manual/rewrite/tech.xml.fr b/docs/manual/rewrite/tech.xml.fr index 6da48f0a82..6c5b87e184 100644 --- a/docs/manual/rewrite/tech.xml.fr +++ b/docs/manual/rewrite/tech.xml.fr @@ -1,7 +1,7 @@ <?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 --> @@ -42,88 +42,94 @@ correspondance</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="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> |