URI: rewrite_flags.html.en
Content-Language: en
Content-type: text/html; charset=ISO-8859-1
+
+URI: rewrite_flags.html.fr
+Content-Language: fr
+Content-type: text/html; charset=ISO-8859-1
--- /dev/null
+<?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">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr"><head><!--
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ This file is generated from xml source: DO NOT EDIT
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ -->
+<title>Les drapeaux du 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" />
+<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" />
+<link href="../images/favicon.ico" rel="shortcut icon" /></head>
+<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>
+<img alt="" src="../images/feather.gif" /></div>
+<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
+<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>Les drapeaux du module Apache mod_rewrite</h1>
+<div class="toplang">
+<p><span>Langues Disponibles: </span><a href="../en/rewrite/rewrite_flags.html" hreflang="en" rel="alternate" title="English"> en </a> |
+<a href="../fr/rewrite/rewrite_flags.html" title="Français"> fr </a></p>
+</div>
+
+<p>Ce document décrit les drapeaux disponibles dans la directive
+<code class="directive"><a href="../mod/mod_rewrite.html#rewriterule">RewriteRule</a></code>, en fournissant
+des explications détaillées et des exemples. Vous n'y trouverez pas
+une liste exhaustive de tous les drapeaux disponibles, c'est pourquoi
+vous devez aussi consulter la documentation de référence.</p>
+</div>
+<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#introduction">Introduction</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#flags">Les drapeaux</a></li>
+</ul><h3>Voir aussi</h3><ul class="seealso"><li><a href="../mod/mod_rewrite.html">Documentation du module</a></li><li><a href="rewrite_tech.html">Détails techniques</a></li><li><a href="rewrite_guide.html">Guide de réécriture - exemples
+utiles</a></li><li><a href="rewrite_guide_advanced.html">Guide de réécriture
+avancée - exemples utiles avancés</a></li></ul></div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="introduction" id="introduction">Introduction</a></h2>
+<p>Le comportement des directives <code class="directive"><a href="../mod/mod_rewrite.html#rewriterule">RewriteRule</a></code> peut être modifié par un ou
+plusieurs drapeaux. Les drapeaux sont situés en fin de règle, entourés
+de crochets, et séparés le cas échéant par des virgules.</p>
+<div class="example"><p><code>
+RewriteRule modèle cible [drapeau1,drapeau2,drapeau3]
+</code></p></div>
+
+<p>Les drapeaux ont tous une forme courte, comme <code>CO</code>, ainsi
+qu'une forme longue, comme <code>cookie</code>. Certains drapeaux
+peuvent avoir un ou plusieurs arguments. Les drapeaux sont insensibles à
+la casse.</p>
+
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="flags" id="flags">Les drapeaux</a></h2>
+
+<p>Chaque drapeau possède une forme longue et une forme courte. Bien que
+la forme courte soit la plus couramment utilisée, nous vous recommandons
+de vous familiariser avec les drapeaux sous leur forme longue, afin de
+bien mémoriser ce que chaque drapeau est supposé faire.</p>
+
+<p>Chaque drapeau disponible est présenté ici, avec un exemple
+d'utilisation.</p>
+
+<h3><a name="flag_c" id="flag_c">C|chain</a></h3>
+<p>Le drapeau [C] ou [chain] indique que la règle <code class="directive"><a href="../mod/mod_rewrite.html#rewriterule">RewriteRule</a></code> est chaînée avec la
+suivante. Autrement dit, si la règle s'applique, elle est traitée
+normalement et passe le contrôle à la règle suivante. Par contre, si
+elle ne s'applique pas, la règle suivante, ainsi que toutes les règles
+chaînées qui suivent, seront sautées.</p>
+
+
+
+<h3><a name="flag_co" id="flag_co">CO|cookie</a></h3>
+<p>Le drapeau [CO], ou [cookie], vous permet de définir un cookie
+lorsqu'une règle <code class="directive"><a href="../mod/mod_rewrite.html#rewriterule">RewriteRule</a></code>
+s'applique. Il possède cinq arguments dont trois sont obligatoires et
+deux optionnels.</p>
+<p>Vous devez déclarer un nom et une valeur pour définir le cookie,
+ainsi que le domaine pour lequel vous souhaitez que le cookie soit
+valide. Vous pouvez aussi définir la durée de vie du cookie, ainsi que
+le chemin pour lequel il doit être renvoyé.</p>
+<p>Par défaut, la durée de vie du cookie correspond à la session du
+navigateur en cours.</p>
+<p>Par défaut, le chemin pour lequel le cookie sera valide est "/" -
+c'est à dire, pour tout le site web.</p>
+<p>Voici un exemple :</p>
+
+<div class="example"><p><code>
+RewriteEngine On<br />
+RewriteRule ^/index\.html - [CO=frontdoor:yes:.apache.org:1440:/]
+</code></p></div>
+
+<p>Cette règle ne réécrit pas la requête (la cible de réécriture "-"
+indique à mod_rewrite de transmettre la requête sans modification), mais
+définit un cookie nommé 'frontdoor' avec une valeur 'yes'. Le cookie est
+valide pour tout hôte situé dans le domaine <code>.apache.org</code>. Sa
+durée de vie est limitée à 1440 minutes (24 heures), et il sera renvoyé
+pour tous les URIs.</p>
+
+
+
+<h3><a name="flag_e" id="flag_e">E|env</a></h3>
+<p>Avec le drapeau [E], ou [env], vous pouvez définir la valeur d'une
+variable d'environnement. Notez que certaines variables d'environnement
+peuvent être définies après le traitement de la règle, annulant par
+la-même ce que vous avez défini. Voir le <a href="../env.html">document
+sur les variables d'environnement</a> pour plus de détails sur le
+fonctionnement des variables d'environnement.</p>
+
+<p>L'exemple suivant définit une variable d'environnement nommée 'image'
+avec une valeur de '1' si l'URI de la requête correspond à un fichier
+image. Cette variable d'environnement est ensuite utilisée pour exclure
+une telle requête du journal des accès.</p>
+
+<div class="example"><p><code>
+RewriteRule \.(png|gif|jpg) - [E=image:1]<br />
+CustomLog logs/access_log combined env=!image
+</code></p></div>
+
+<p>Notez que le même effet peut être obtenu à l'aide de la directive
+<code class="directive"><a href="../mod/mod_setenvif.html#setenvif">SetEnvIf</a></code>. Cette technique
+est présentée à titre d'exemple et non de recommandation.</p>
+
+
+<h3><a name="flag_f" id="flag_f">F|forbidden</a></h3>
+<p>L'utilisation du drapeau [F] permet de faire envoyer par Apache au
+client un code de statut "403 Forbidden". Le même effet peut être obtenu à
+l'aide de la directive <code class="directive"><a href="../mod/mod_access.html#deny">Deny</a></code>,
+mais ce drapeau offre plus de souplesse dans l'attribution d'un statut
+Forbidden.</p>
+
+<p>La règle suivante va interdire la téléchargement de fichiers
+<code>.exe</code> depuis votre serveur.</p>
+
+<div class="example"><p><code>
+RewriteRule \.exe - [F]
+</code></p></div>
+
+<p>Cet exemple utilise la syntaxe "-" pour la cible de réécriture, ce
+qui signifie que l'URI de la requête n'est pas modifié. Il n'y a aucune
+raison de réécrire un URI, si vous avez l'intention d'interdire la
+requête.</p>
+
+
+
+<h3><a name="flag_g" id="flag_g">G|gone</a></h3>
+<p>Le drapeau [G] permet de faire envoyer par Apache un code de statut
+"410 Gone" avec la réponse. Ce code indique qu'une ressource qui était
+disponible auparavant ne l'est plus actuellement.</p>
+
+<p>Comme dans le cas du drapeau [F], on utilise en général la syntaxe
+"-" pour la cible de réécriture lorsqu'on utilise le drapeau [G] :</p>
+
+<div class="example"><p><code>
+RewriteRule ancienne-ressource - [G,NC]
+</code></p></div>
+
+
+<h3><a name="flag_h" id="flag_h">H|handler</a></h3>
+<p>Force le traitement de la requête résultante par le gestionnaire
+spécifié. Par exemple, on peut utiliser ce drapeau pour forcer
+l'interprétation de tous les fichiers sans extension par le gestionnaire
+php :</p>
+
+<div class="example"><p><code>
+RewriteRule !\. - [H=application/x-httpd-php]
+</code></p></div>
+
+<p>
+L'expression rationnelle ci-dessus - <code>!\.</code> - correspond à
+toute requête qui ne contient pas le caractère <code>.</code>.
+</p>
+<p>On peut aussi utiliser ce drapeau pour forcer l'utilisation d'un
+certain gestionnaire en fonction de certaines conditions. Par exemple,
+l'extrait suivant utilisé dans un contexte de niveau serveur permet de
+faire en sorte que les fichiers <code>.php</code> soient
+<em>affichés</em> par <code>mod_php</code> dans le cas où ils font
+l'objet d'une requête avec l'extension <code>.phps</code> :
+
+<div class="example"><p><code>
+RewriteRule ^(/source/.+\.php)s$ $1 [H=application/x-httpd-php-source]
+</code></p></div>
+</p>
+
+<p>L'expression rationnelle ci-dessus -
+<code>^(/source/.+\.php)s$</code> - va correspondre à toute requête qui
+débutera par <code>/source/</code>, continuera par 1 ou n caractères
+puis par <code>.phps</code>. La référence arrière $1 fait référence à la
+correspondance capturée entre parenthèses de l'expression
+rationnelle.</p>
+
+
+
+
+<h3><a name="flag_l" id="flag_l">L|last</a></h3>
+<p>Lorsque le drapeau [L] est présent, <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>
+arrête le traitement du jeu de règles. Cela signifie dans la plupart des
+situations que si la règle s'applique, aucune autre règle ne sera
+traitée.</p>
+
+<p>Si vous utilisez des règles <code class="directive"><a href="../mod/mod_rewrite.html#rewriterule">RewriteRule</a></code> dans des fichiers
+<code>.htaccess</code> ou des sections <code class="directive"><a href="../mod/core.html#directory"><Directory></a></code>, il est important d'avoir quelques
+notions sur la manière dont les règles sont traitées. Pour simplifier,
+une fois les règles traitées, la requête réécrite est passée à nouveau
+au moteur d'interprétation des URLs afin que ce dernier puisse la
+traiter. Il est possible qu'au cours du traitement de la requête
+réécrite, le fichier <code>.htaccess</code> ou la section <code class="directive"><a href="../mod/core.html#directory"><Directory></a></code> soient à nouveau
+rencontrés, entraînant un nouveau traitement du jeu de règles depuis le
+début. Cette situation se présente le plus souvent lorsqu'une des règles
+provoque une redirection - interne ou externe - ce qui réinitialise le
+traitement de la requête.</p>
+
+<p>Si vous utilisez des directives <code class="directive"><a href="../mod/mod_rewrite.html#rewriterule">RewriteRule</a></code> dans un de ces contextes,
+il importe par conséquent de prévoir explicitement des étapes permettant
+d'éviter un bouclage infini sur les règles,
+et de ne pas compter seulement sur
+le drapeau [L] pour terminer l'exécution d'une série de règles, comme
+décrit ci-dessous.</p>
+
+<p>Dans l'exemple donné ici, toute requête est réécrite en
+<code>index.php</code>, la requête originale étant ajoutée comme chaîne
+de requête en argument à <code>index.php</code> ; cependant, la
+directive <code class="directive"><a href="../mod/mod_rewrite.html#rewritecond">RewriteCond</a></code> permet de s'assurer que si
+la requête concerne déjà <code>index.php</code>, la directive <code class="directive"><a href="../mod/mod_rewrite.html#rewriterule">RewriteRule</a></code> sera sautée.</p>
+
+<div class="example"><p><code>
+RewriteCond %{REQUEST_URI} !=index\.php<br />
+RewriteRule ^(.*) index.php?req=$1 [L]
+</code></p></div>
+
+
+<h3><a name="flag_n" id="flag_n">N|next</a></h3>
+<p>Le drapeau [N] provoque un redémarrage du traitement des règles
+depuis le début ; à utiliser avec précautions car il peut provoquer un
+bouclage infini.
+</p>
+<p>
+Le drapeau [Next] peut servir, par exemple,
+à remplacer de manière répétitive
+une chaîne de caractère ou une lettre dans une requête. Dans l'exemple
+suivant, chaque occurence de A sera remplacée par B dans la requête, et
+ceci jusqu'il n'y ait plus de A à remplacer.
+</p>
+
+<div class="example"><p><code>
+RewriteRule (.*)A(.*) $1B$2 [N]
+</code></p></div>
+
+<p>Vous pouvez vous représenter ce traitement comme une boucle
+<code>while</code> : tant que le modèle de la règle correspond (c'est à
+dire, tant que l'URI contient un <code>A</code>),
+effectuer la substitution (c'est à dire, remplacer le <code>A</code> par
+un <code>B</code>).</p>
+
+
+
+<h3><a name="flag_nc" id="flag_nc">NC|nocase</a></h3>
+<p>Avec le drapeau [NC], le modèle de la règle <code class="directive"><a href="../mod/mod_rewrite.html#rewriterule">RewriteRule</a></code> est comparé à la requête de
+manière insensible à la casse. C'est à dire que cette comparaison
+s'effectue sans tenir compte des majuscules/minuscules dans l'URI
+comparé.</p>
+
+<p>Dans l'exemple suivant, toute requête pour un fichier image sera
+transmise par Apache à votre serveur d'images dédié. La correspondance est
+insensible à la casse, si bien que par exemple, <code>.jpg</code> aussi
+bien que <code>.JPG</code> seront acceptés.</p>
+
+<div class="example"><p><code>
+RewriteRule (.*\.(jpg|gif|png))$ http://images.example.com$1 [P,NC]
+</code></p></div>
+
+
+<h3><a name="flag_ne" id="flag_ne">NE|noescape</a></h3>
+<p>Par défaut, les caractères spéciaux, comme <code>&</code> et
+<code>?</code>, sont convertis en leur équivalent
+hexadécimal. Le drapeau [NE] permet d'éviter cette conversion.
+</p>
+
+<div class="example"><p><code>
+RewriteRule ^/ancre/(.+) /grosse-page.html#$1 [NE,R]
+</code></p></div>
+
+<p>
+Dans l'exemple ci-dessus, <code>/anchor/xyz</code> est réécrit en
+<code>/bigpage.html#xyz</code>. En l'absence du drapeau [NE], le #
+aurait été converti en son équivalent hexadécimal, <code>%23</code>, ce
+qui aurait provoqué un code d'erreur "404 Not Found".
+</p>
+
+
+
+<h3><a name="flag_ns" id="flag_ns">NS|nosubreq</a></h3>
+<p>Le drapeau [NS] empêche la règle de s'appliquer aux sous-requêtes.
+Par exemple, une page incluse au moyen d'une SSI (Server
+Side Include) est une sous-requête, et vous ne voudrez peut-être pas que
+la réécriture s'applique à ces sous-requêtes.</p>
+
+<p>
+Les images, scripts java, ou fichiers css, chargés en tant que partie
+d'une page html, ne sont pas des sous-requêtes - le navigateur les
+appelle sous forme de requêtes HTTP à part entière.
+</p>
+
+
+<h3><a name="flag_p" id="flag_p">P|proxy</a></h3>
+<p>L'utilisation du drapeau [P] entraîne le traitement de la requête par
+le module <code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code>, et ceci via une requête de
+mandataire. Par exemple, si vous voulez que toutes les requêtes d'images
+soient traitées par un serveur d'images annexe, vous pouvez utiliser
+une règle de ce style :</p>
+
+<div class="example"><p><code>
+RewriteRule (.*)\.(jpg|gif|png) http://images.exemple.com$1.$2 [P]
+</code></p></div>
+
+<p>L'utilisation du drapeau [P] provoque aussi l'effet du drapeau [L] -
+autrement dit, la requête est immédiatement envoyée au mandataire, et
+toute règle ultérieure sera ignorée.</p>
+
+
+
+<h3><a name="flag_pt" id="flag_pt">PT|passthrough</a></h3>
+
+<p>
+Par défaut, la cible (ou chaîne de substitution) d'une règle
+RewriteRule est sensée être un chemin de fichier. Avec le drapeau [PT],
+par contre, elle est traitée comme un URI. Autrement dit, avec le
+drapeau [PT], le résultat de la règle <code class="directive"><a href="../mod/mod_rewrite.html#rewriterule">RewriteRule</a></code> est passé à nouveau au
+système de mise en correspondance des URLs avec le système de fichiers,
+de façon à ce que les systèmes de mise en correspondance basés sur les
+chemins de fichiers, comme la directive <code class="directive"><a href="../mod/mod_alias.html#alias">Alias</a></code>, par exemple, puissent avoir une
+chance d'accomplir leur tâche.
+</p>
+
+<p>
+Si par exemple, vous avez un <code class="directive"><a href="../mod/mod_alias.html#alias">Alias</a></code> pour /icons, et une règle <code class="directive"><a href="../mod/mod_rewrite.html#rewriterule">RewriteRule</a></code> qui renvoie vers /icons,
+vous devez utiliser le drapeau [PT] pour être sûr que l'<code class="directive"><a href="../mod/mod_alias.html#alias">Alias</a></code> sera bien évalué.
+</p>
+
+<div class="example"><p><code>
+Alias /icons /usr/local/apache/icons<br />
+RewriteRule /pics/(.+)\.jpg /icons/$1.gif [PT]
+</code></p></div>
+
+<p>
+Dans l'exemple précédent, en l'absence du drapeau [PT], l'Alias aurait
+été ignoré, ce qui aurait provoqué une erreur 'File not found'.
+</p>
+
+
+
+<h3><a name="flag_qsa" id="flag_qsa">QSA|qsappend</a></h3>
+<p>
+Quand l'URI de remplacement contient une chaîne de requête, le
+comportement par défaut de la règle <code class="directive"><a href="../mod/mod_rewrite.html#rewriterule">RewriteRule</a></code> est de supprimer la <code>
+query string</code> (il s'agit des paramètres éventuellement passés dans l'URL après le
+caractère <code>?</code>, usuellement pour les formulaires traités par la
+méthode HTTP <code>GET</code>) existante, et de la remplacer par celle nouvellement créée.
+Avec le drapeau [QSA], les chaînes de requête peuvent être combinées.
+</p>
+
+<p>Considérons la règle suivante :</p>
+
+<div class="example"><p><code>
+RewriteRule /pages/(.+) /page.php?page=$1 [QSA]
+</code></p></div>
+
+<p>Avec le drapeau [QSA], une requête pour
+<code>/pages/123?one=two</code> sera réécrite en
+<code>/page.php?page=123&one=two</code>. Sans le drapeau [QSA], la
+même requête sera réécrite en <code>/page.php?page=123</code> -
+autrement dit, la chaîne de requête (<code>query string</code>) existante sera supprimée.
+</p>
+
+
+<h3><a name="flag_r" id="flag_r">R|redirect</a></h3>
+<p>
+L'utilisation du drapeau [R] provoque l'envoi d'une redirection au
+navigateur. Si une URL pleinement qualifiée (FQDN - fully qualified domain name)
+ est spécifiée (c'est à dire incluant <code>http://nom-du-serveur/</code>),
+ une redirection sera effectuée vers cette adresse. Dans le cas contraire,
+ c'est le nom du serveur local qui sera utilisé pour générer l'URL envoyée avec la
+redirection.
+</p>
+
+<p>
+Un code de statut entre 300 et 399 peut être spécifié, le code 302 étant
+utilisé par défaut si aucun code n'est spécifié.
+</p>
+
+<p>
+Vous utiliserez presque toujours [R] en conjonction avec [L] (c'est à
+dire [R,L]), car employé seul, le drapeau [R] préfixe l'URI avec
+<code>http://cet-hôte[:ce-port]</code>, mais passe ensuite cette adresse
+à la règle suivante, ce qui provoquera le plus souvent des
+avertissements 'Invalid URI in request'.
+</p>
+
+
+
+<h3><a name="flag_s" id="flag_s">S|skip</a></h3>
+<p>Le drapeau [S] sert à sauter des règles que vous ne voulez pas voir
+exécuter. Ceci peut s'interpréter comme une instruction
+<code>goto</code> dans votre jeu de règles de réécriture. Dans
+l'exemple suivant, nous ne voulons exécuter la règle <code class="directive"><a href="../mod/mod_rewrite.html#rewriterule">RewriteRule</a></code> que si l'URI demandé ne
+correspond pas à un fichier existant.</p>
+
+<div class="example"><p><code>
+# La requête concerne-t-elle un fichier qui n'existe pas ?<br />
+RewriteCond %{REQUEST_FILENAME} !-f<br />
+RewriteCond %{REQUEST_FILENAME} !-d<br />
+# Si c'est la cas, on saute les deux règles de réécriture suivantes<br />
+RewriteRule .? - [S=2]<br />
+<br />
+RewriteRule (.*\.gif) images.php?$1<br />
+RewriteRule (.*\.html) docs.php?$1
+</code></p></div>
+
+<p>Cette technique trouve son utilité dans le fait qu'une directive
+<code class="directive"><a href="../mod/mod_rewrite.html#rewritecond">RewriteCond</a></code> ne s'applique
+qu'à la règle qui la suit immédiatement. Ainsi, si vous voulez
+qu'une directive <code>RewriteCond</code> s'applique à plusieurs règles
+<code>RewriteRule</code>, vous pouvez utiliser le drapeau [Skip].</p>
+
+
+
+<h3><a name="flag_t" id="flag_t">T|type</a></h3>
+<p>Définit le type MIME de la réponse résultante renvoyée. L'effet est
+identique à celui de la directive <code class="directive"><a href="../mod/mod_mime.html#addtype">AddType</a></code>.</p>
+
+<p>Par exemple, vous pouvez utiliser la technique suivante pour servir
+du code source Perl en tant que plein texte, s'il est requis d'une
+certaine manière :</p>
+
+<div class="example"><p><code>
+# Sert les fichier .pl en tant que plein texte<br />
+RewriteRule \.pl$ - [T=text/plain]
+</code></p></div>
+
+<p>Ou encore, si vous possédez une caméra qui produit des fichiers
+images jpeg sans extension, vous pouvez forcer le renvoi de ces images
+avec le type MIME correct en se basant sur le nom du fichier :</p>
+
+<div class="example"><p><code>
+# Les fichiers dont le nom contient 'IMG' sont des images jpg.<br />
+RewriteRule IMG - [T=image/jpg]
+</code></p></div>
+
+<p>Notez cependant qu'il s'agit d'un exemple trivial, et que le problème
+aurait pu être résolu en utilisant à la place la directive <code class="directive"><a href="../mod/core.html#filesmatch"><FilesMatch></a></code>. Il faut toujours
+envisager la possibilité d'une solution alternative à un problème avant
+d'avoir recours à la réécriture, qui sera toujours moins efficace qu'une
+solution alternative.</p>
+
+
+</div></div>
+<div class="bottomlang">
+<p><span>Langues Disponibles: </span><a href="../en/rewrite/rewrite_flags.html" hreflang="en" rel="alternate" title="English"> en </a> |
+<a href="../fr/rewrite/rewrite_flags.html" title="Français"> fr </a></p>
+</div><div id="footer">
+<p class="apache">Copyright 2009 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>
\ No newline at end of file
--- /dev/null
+<?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 : 728398 -->
+<!-- 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="rewrite_flags.xml.meta">
+<parentdocument href="./">Rewrite</parentdocument>
+
+ <title>Les drapeaux du module Apache mod_rewrite</title>
+
+<summary>
+<p>Ce document décrit les drapeaux disponibles dans la directive
+<directive module="mod_rewrite">RewriteRule</directive>, en fournissant
+des explications détaillées et des exemples. Vous n'y trouverez pas
+une liste exhaustive de tous les drapeaux disponibles, c'est pourquoi
+vous devez aussi consulter la documentation de référence.</p>
+</summary>
+
+<seealso><a href="../mod/mod_rewrite.html">Documentation du module</a></seealso>
+<seealso><a href="rewrite_tech.html">Détails techniques</a></seealso>
+<seealso><a href="rewrite_guide.html">Guide de réécriture - exemples
+utiles</a></seealso>
+<seealso><a href="rewrite_guide_advanced.html">Guide de réécriture
+avancée - exemples utiles avancés</a></seealso>
+
+<section id="introduction"><title>Introduction</title>
+<p>Le comportement des directives <directive
+module="mod_rewrite">RewriteRule</directive> peut être modifié par un ou
+plusieurs drapeaux. Les drapeaux sont situés en fin de règle, entourés
+de crochets, et séparés le cas échéant par des virgules.</p>
+<example>
+RewriteRule modèle cible [drapeau1,drapeau2,drapeau3]
+</example>
+
+<p>Les drapeaux ont tous une forme courte, comme <code>CO</code>, ainsi
+qu'une forme longue, comme <code>cookie</code>. Certains drapeaux
+peuvent avoir un ou plusieurs arguments. Les drapeaux sont insensibles à
+la casse.</p>
+
+</section>
+
+<section id="flags"><title>Les drapeaux</title>
+
+<p>Chaque drapeau possède une forme longue et une forme courte. Bien que
+la forme courte soit la plus couramment utilisée, nous vous recommandons
+de vous familiariser avec les drapeaux sous leur forme longue, afin de
+bien mémoriser ce que chaque drapeau est supposé faire.</p>
+
+<p>Chaque drapeau disponible est présenté ici, avec un exemple
+d'utilisation.</p>
+
+<section id="flag_c"><title>C|chain</title>
+<p>Le drapeau [C] ou [chain] indique que la règle <directive
+module="mod_rewrite">RewriteRule</directive> est chaînée avec la
+suivante. Autrement dit, si la règle s'applique, elle est traitée
+normalement et passe le contrôle à la règle suivante. Par contre, si
+elle ne s'applique pas, la règle suivante, ainsi que toutes les règles
+chaînées qui suivent, seront sautées.</p>
+
+</section>
+
+<section id="flag_co"><title>CO|cookie</title>
+<p>Le drapeau [CO], ou [cookie], vous permet de définir un cookie
+lorsqu'une règle <directive module="mod_rewrite">RewriteRule</directive>
+s'applique. Il possède cinq arguments dont trois sont obligatoires et
+deux optionnels.</p>
+<p>Vous devez déclarer un nom et une valeur pour définir le cookie,
+ainsi que le domaine pour lequel vous souhaitez que le cookie soit
+valide. Vous pouvez aussi définir la durée de vie du cookie, ainsi que
+le chemin pour lequel il doit être renvoyé.</p>
+<p>Par défaut, la durée de vie du cookie correspond à la session du
+navigateur en cours.</p>
+<p>Par défaut, le chemin pour lequel le cookie sera valide est "/" -
+c'est à dire, pour tout le site web.</p>
+<p>Voici un exemple :</p>
+
+<example>
+RewriteEngine On<br />
+RewriteRule ^/index\.html - [CO=frontdoor:yes:.apache.org:1440:/]
+</example>
+
+<p>Cette règle ne réécrit pas la requête (la cible de réécriture "-"
+indique à mod_rewrite de transmettre la requête sans modification), mais
+définit un cookie nommé 'frontdoor' avec une valeur 'yes'. Le cookie est
+valide pour tout hôte situé dans le domaine <code>.apache.org</code>. Sa
+durée de vie est limitée à 1440 minutes (24 heures), et il sera renvoyé
+pour tous les URIs.</p>
+
+</section>
+
+<section id="flag_e"><title>E|env</title>
+<p>Avec le drapeau [E], ou [env], vous pouvez définir la valeur d'une
+variable d'environnement. Notez que certaines variables d'environnement
+peuvent être définies après le traitement de la règle, annulant par
+la-même ce que vous avez défini. Voir le <a href="../env.html">document
+sur les variables d'environnement</a> pour plus de détails sur le
+fonctionnement des variables d'environnement.</p>
+
+<p>L'exemple suivant définit une variable d'environnement nommée 'image'
+avec une valeur de '1' si l'URI de la requête correspond à un fichier
+image. Cette variable d'environnement est ensuite utilisée pour exclure
+une telle requête du journal des accès.</p>
+
+<example>
+RewriteRule \.(png|gif|jpg) - [E=image:1]<br />
+CustomLog logs/access_log combined env=!image
+</example>
+
+<p>Notez que le même effet peut être obtenu à l'aide de la directive
+<directive module="mod_setenvif">SetEnvIf</directive>. Cette technique
+est présentée à titre d'exemple et non de recommandation.</p>
+</section>
+
+<section id="flag_f"><title>F|forbidden</title>
+<p>L'utilisation du drapeau [F] permet de faire envoyer par Apache au
+client un code de statut "403 Forbidden". Le même effet peut être obtenu à
+l'aide de la directive <directive module="mod_access">Deny</directive>,
+mais ce drapeau offre plus de souplesse dans l'attribution d'un statut
+Forbidden.</p>
+
+<p>La règle suivante va interdire la téléchargement de fichiers
+<code>.exe</code> depuis votre serveur.</p>
+
+<example>
+RewriteRule \.exe - [F]
+</example>
+
+<p>Cet exemple utilise la syntaxe "-" pour la cible de réécriture, ce
+qui signifie que l'URI de la requête n'est pas modifié. Il n'y a aucune
+raison de réécrire un URI, si vous avez l'intention d'interdire la
+requête.</p>
+
+</section>
+
+<section id="flag_g"><title>G|gone</title>
+<p>Le drapeau [G] permet de faire envoyer par Apache un code de statut
+"410 Gone" avec la réponse. Ce code indique qu'une ressource qui était
+disponible auparavant ne l'est plus actuellement.</p>
+
+<p>Comme dans le cas du drapeau [F], on utilise en général la syntaxe
+"-" pour la cible de réécriture lorsqu'on utilise le drapeau [G] :</p>
+
+<example>
+RewriteRule ancienne-ressource - [G,NC]
+</example>
+</section>
+
+<section id="flag_h"><title>H|handler</title>
+<p>Force le traitement de la requête résultante par le gestionnaire
+spécifié. Par exemple, on peut utiliser ce drapeau pour forcer
+l'interprétation de tous les fichiers sans extension par le gestionnaire
+php :</p>
+
+<example>
+RewriteRule !\. - [H=application/x-httpd-php]
+</example>
+
+<p>
+L'expression rationnelle ci-dessus - <code>!\.</code> - correspond à
+toute requête qui ne contient pas le caractère <code>.</code>.
+</p>
+<p>On peut aussi utiliser ce drapeau pour forcer l'utilisation d'un
+certain gestionnaire en fonction de certaines conditions. Par exemple,
+l'extrait suivant utilisé dans un contexte de niveau serveur permet de
+faire en sorte que les fichiers <code>.php</code> soient
+<em>affichés</em> par <code>mod_php</code> dans le cas où ils font
+l'objet d'une requête avec l'extension <code>.phps</code> :
+
+<example>
+RewriteRule ^(/source/.+\.php)s$ $1 [H=application/x-httpd-php-source]
+</example>
+</p>
+
+<p>L'expression rationnelle ci-dessus -
+<code>^(/source/.+\.php)s$</code> - va correspondre à toute requête qui
+débutera par <code>/source/</code>, continuera par 1 ou n caractères
+puis par <code>.phps</code>. La référence arrière $1 fait référence à la
+correspondance capturée entre parenthèses de l'expression
+rationnelle.</p>
+
+
+</section>
+
+<section id="flag_l"><title>L|last</title>
+<p>Lorsque le drapeau [L] est présent, <module>mod_rewrite</module>
+arrête le traitement du jeu de règles. Cela signifie dans la plupart des
+situations que si la règle s'applique, aucune autre règle ne sera
+traitée.</p>
+
+<p>Si vous utilisez des règles <directive
+module="mod_rewrite">RewriteRule</directive> dans des fichiers
+<code>.htaccess</code> ou des sections <directive type="section"
+module="core">Directory</directive>, il est important d'avoir quelques
+notions sur la manière dont les règles sont traitées. Pour simplifier,
+une fois les règles traitées, la requête réécrite est passée à nouveau
+au moteur d'interprétation des URLs afin que ce dernier puisse la
+traiter. Il est possible qu'au cours du traitement de la requête
+réécrite, le fichier <code>.htaccess</code> ou la section <directive
+type="section" module="core">Directory</directive> soient à nouveau
+rencontrés, entraînant un nouveau traitement du jeu de règles depuis le
+début. Cette situation se présente le plus souvent lorsqu'une des règles
+provoque une redirection - interne ou externe - ce qui réinitialise le
+traitement de la requête.</p>
+
+<p>Si vous utilisez des directives <directive
+module="mod_rewrite">RewriteRule</directive> dans un de ces contextes,
+il importe par conséquent de prévoir explicitement des étapes permettant
+d'éviter un bouclage infini sur les règles,
+et de ne pas compter seulement sur
+le drapeau [L] pour terminer l'exécution d'une série de règles, comme
+décrit ci-dessous.</p>
+
+<p>Dans l'exemple donné ici, toute requête est réécrite en
+<code>index.php</code>, la requête originale étant ajoutée comme chaîne
+de requête en argument à <code>index.php</code> ; cependant, la
+directive <directive
+module="mod_rewrite">RewriteCond</directive> permet de s'assurer que si
+la requête concerne déjà <code>index.php</code>, la directive <directive
+module="mod_rewrite">RewriteRule</directive> sera sautée.</p>
+
+<example>
+RewriteCond %{REQUEST_URI} !=index\.php<br />
+RewriteRule ^(.*) index.php?req=$1 [L]
+</example>
+</section>
+
+<section id="flag_n"><title>N|next</title>
+<p>Le drapeau [N] provoque un redémarrage du traitement des règles
+depuis le début ; à utiliser avec précautions car il peut provoquer un
+bouclage infini.
+</p>
+<p>
+Le drapeau [Next] peut servir, par exemple,
+à remplacer de manière répétitive
+une chaîne de caractère ou une lettre dans une requête. Dans l'exemple
+suivant, chaque occurence de A sera remplacée par B dans la requête, et
+ceci jusqu'il n'y ait plus de A à remplacer.
+</p>
+
+<example>
+RewriteRule (.*)A(.*) $1B$2 [N]
+</example>
+
+<p>Vous pouvez vous représenter ce traitement comme une boucle
+<code>while</code> : tant que le modèle de la règle correspond (c'est à
+dire, tant que l'URI contient un <code>A</code>),
+effectuer la substitution (c'est à dire, remplacer le <code>A</code> par
+un <code>B</code>).</p>
+
+</section>
+
+<section id="flag_nc"><title>NC|nocase</title>
+<p>Avec le drapeau [NC], le modèle de la règle <directive
+module="mod_rewrite">RewriteRule</directive> est comparé à la requête de
+manière insensible à la casse. C'est à dire que cette comparaison
+s'effectue sans tenir compte des majuscules/minuscules dans l'URI
+comparé.</p>
+
+<p>Dans l'exemple suivant, toute requête pour un fichier image sera
+transmise par Apache à votre serveur d'images dédié. La correspondance est
+insensible à la casse, si bien que par exemple, <code>.jpg</code> aussi
+bien que <code>.JPG</code> seront acceptés.</p>
+
+<example>
+RewriteRule (.*\.(jpg|gif|png))$ http://images.example.com$1 [P,NC]
+</example>
+</section>
+
+<section id="flag_ne"><title>NE|noescape</title>
+<p>Par défaut, les caractères spéciaux, comme <code>&</code> et
+<code>?</code>, sont convertis en leur équivalent
+hexadécimal. Le drapeau [NE] permet d'éviter cette conversion.
+</p>
+
+<example>
+RewriteRule ^/ancre/(.+) /grosse-page.html#$1 [NE,R]
+</example>
+
+<p>
+Dans l'exemple ci-dessus, <code>/anchor/xyz</code> est réécrit en
+<code>/bigpage.html#xyz</code>. En l'absence du drapeau [NE], le #
+aurait été converti en son équivalent hexadécimal, <code>%23</code>, ce
+qui aurait provoqué un code d'erreur "404 Not Found".
+</p>
+
+</section>
+
+<section id="flag_ns"><title>NS|nosubreq</title>
+<p>Le drapeau [NS] empêche la règle de s'appliquer aux sous-requêtes.
+Par exemple, une page incluse au moyen d'une SSI (Server
+Side Include) est une sous-requête, et vous ne voudrez peut-être pas que
+la réécriture s'applique à ces sous-requêtes.</p>
+
+<p>
+Les images, scripts java, ou fichiers css, chargés en tant que partie
+d'une page html, ne sont pas des sous-requêtes - le navigateur les
+appelle sous forme de requêtes HTTP à part entière.
+</p>
+</section>
+
+<section id="flag_p"><title>P|proxy</title>
+<p>L'utilisation du drapeau [P] entraîne le traitement de la requête par
+le module <module>mod_proxy</module>, et ceci via une requête de
+mandataire. Par exemple, si vous voulez que toutes les requêtes d'images
+soient traitées par un serveur d'images annexe, vous pouvez utiliser
+une règle de ce style :</p>
+
+<example>
+RewriteRule (.*)\.(jpg|gif|png) http://images.exemple.com$1.$2 [P]
+</example>
+
+<p>L'utilisation du drapeau [P] provoque aussi l'effet du drapeau [L] -
+autrement dit, la requête est immédiatement envoyée au mandataire, et
+toute règle ultérieure sera ignorée.</p>
+
+</section>
+
+<section id="flag_pt"><title>PT|passthrough</title>
+
+<p>
+Par défaut, la cible (ou chaîne de substitution) d'une règle
+RewriteRule est sensée être un chemin de fichier. Avec le drapeau [PT],
+par contre, elle est traitée comme un URI. Autrement dit, avec le
+drapeau [PT], le résultat de la règle <directive
+module="mod_rewrite">RewriteRule</directive> est passé à nouveau au
+système de mise en correspondance des URLs avec le système de fichiers,
+de façon à ce que les systèmes de mise en correspondance basés sur les
+chemins de fichiers, comme la directive <directive
+module="mod_alias">Alias</directive>, par exemple, puissent avoir une
+chance d'accomplir leur tâche.
+</p>
+
+<p>
+Si par exemple, vous avez un <directive
+module="mod_alias">Alias</directive> pour /icons, et une règle <directive
+module="mod_rewrite">RewriteRule</directive> qui renvoie vers /icons,
+vous devez utiliser le drapeau [PT] pour être sûr que l'<directive
+module="mod_alias">Alias</directive> sera bien évalué.
+</p>
+
+<example>
+Alias /icons /usr/local/apache/icons<br />
+RewriteRule /pics/(.+)\.jpg /icons/$1.gif [PT]
+</example>
+
+<p>
+Dans l'exemple précédent, en l'absence du drapeau [PT], l'Alias aurait
+été ignoré, ce qui aurait provoqué une erreur 'File not found'.
+</p>
+
+</section>
+
+<section id="flag_qsa"><title>QSA|qsappend</title>
+<p>
+Quand l'URI de remplacement contient une chaîne de requête, le
+comportement par défaut de la règle <directive
+module="mod_rewrite">RewriteRule</directive> est de supprimer la <code>
+query string</code> (il s'agit des paramètres éventuellement passés dans l'URL après le
+caractère <code>?</code>, usuellement pour les formulaires traités par la
+méthode HTTP <code>GET</code>) existante, et de la remplacer par celle nouvellement créée.
+Avec le drapeau [QSA], les chaînes de requête peuvent être combinées.
+</p>
+
+<p>Considérons la règle suivante :</p>
+
+<example>
+RewriteRule /pages/(.+) /page.php?page=$1 [QSA]
+</example>
+
+<p>Avec le drapeau [QSA], une requête pour
+<code>/pages/123?one=two</code> sera réécrite en
+<code>/page.php?page=123&one=two</code>. Sans le drapeau [QSA], la
+même requête sera réécrite en <code>/page.php?page=123</code> -
+autrement dit, la chaîne de requête (<code>query string</code>) existante sera supprimée.
+</p>
+</section>
+
+<section id="flag_r"><title>R|redirect</title>
+<p>
+L'utilisation du drapeau [R] provoque l'envoi d'une redirection au
+navigateur. Si une URL pleinement qualifiée (FQDN - fully qualified domain name)
+ est spécifiée (c'est à dire incluant <code>http://nom-du-serveur/</code>),
+ une redirection sera effectuée vers cette adresse. Dans le cas contraire,
+ c'est le nom du serveur local qui sera utilisé pour générer l'URL envoyée avec la
+redirection.
+</p>
+
+<p>
+Un code de statut entre 300 et 399 peut être spécifié, le code 302 étant
+utilisé par défaut si aucun code n'est spécifié.
+</p>
+
+<p>
+Vous utiliserez presque toujours [R] en conjonction avec [L] (c'est à
+dire [R,L]), car employé seul, le drapeau [R] préfixe l'URI avec
+<code>http://cet-hôte[:ce-port]</code>, mais passe ensuite cette adresse
+à la règle suivante, ce qui provoquera le plus souvent des
+avertissements 'Invalid URI in request'.
+</p>
+
+</section>
+
+<section id="flag_s"><title>S|skip</title>
+<p>Le drapeau [S] sert à sauter des règles que vous ne voulez pas voir
+exécuter. Ceci peut s'interpréter comme une instruction
+<code>goto</code> dans votre jeu de règles de réécriture. Dans
+l'exemple suivant, nous ne voulons exécuter la règle <directive
+module="mod_rewrite">RewriteRule</directive> que si l'URI demandé ne
+correspond pas à un fichier existant.</p>
+
+<example>
+# La requête concerne-t-elle un fichier qui n'existe pas ?<br />
+RewriteCond %{REQUEST_FILENAME} !-f<br />
+RewriteCond %{REQUEST_FILENAME} !-d<br />
+# Si c'est la cas, on saute les deux règles de réécriture suivantes<br />
+RewriteRule .? - [S=2]<br />
+<br />
+RewriteRule (.*\.gif) images.php?$1<br />
+RewriteRule (.*\.html) docs.php?$1
+</example>
+
+<p>Cette technique trouve son utilité dans le fait qu'une directive
+<directive module="mod_rewrite">RewriteCond</directive> ne s'applique
+qu'à la règle qui la suit immédiatement. Ainsi, si vous voulez
+qu'une directive <code>RewriteCond</code> s'applique à plusieurs règles
+<code>RewriteRule</code>, vous pouvez utiliser le drapeau [Skip].</p>
+
+</section>
+
+<section id="flag_t"><title>T|type</title>
+<p>Définit le type MIME de la réponse résultante renvoyée. L'effet est
+identique à celui de la directive <directive
+module="mod_mime">AddType</directive>.</p>
+
+<p>Par exemple, vous pouvez utiliser la technique suivante pour servir
+du code source Perl en tant que plein texte, s'il est requis d'une
+certaine manière :</p>
+
+<example>
+# Sert les fichier .pl en tant que plein texte<br />
+RewriteRule \.pl$ - [T=text/plain]
+</example>
+
+<p>Ou encore, si vous possédez une caméra qui produit des fichiers
+images jpeg sans extension, vous pouvez forcer le renvoi de ces images
+avec le type MIME correct en se basant sur le nom du fichier :</p>
+
+<example>
+# Les fichiers dont le nom contient 'IMG' sont des images jpg.<br />
+RewriteRule IMG - [T=image/jpg]
+</example>
+
+<p>Notez cependant qu'il s'agit d'un exemple trivial, et que le problème
+aurait pu être résolu en utilisant à la place la directive <directive
+type="section" module="core">FilesMatch</directive>. Il faut toujours
+envisager la possibilité d'une solution alternative à un problème avant
+d'avoir recours à la réécriture, qui sera toujours moins efficace qu'une
+solution alternative.</p>
+</section>
+
+</section>
+</manualpage>
+
<variants>
<variant>en</variant>
+ <variant>fr</variant>
</variants>
</metafile>
URI: rewrite_guide_advanced.html.en
Content-Language: en
Content-type: text/html; charset=ISO-8859-1
+
+URI: rewrite_guide_advanced.html.fr
+Content-Language: fr
+Content-type: text/html; charset=ISO-8859-1
--- /dev/null
+<?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">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr"><head><!--
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ This file is generated from xml source: DO NOT EDIT
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ -->
+<title>Guide de réécriture des URLs - Sujets avancés - 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" />
+<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" />
+<link href="../images/favicon.ico" rel="shortcut icon" /></head>
+<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>
+<img alt="" src="../images/feather.gif" /></div>
+<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
+<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>Guide de réécriture des URLs - Sujets avancés</h1>
+<div class="toplang">
+<p><span>Langues Disponibles: </span><a href="../en/rewrite/rewrite_guide_advanced.html" hreflang="en" rel="alternate" title="English"> en </a> |
+<a href="../fr/rewrite/rewrite_guide_advanced.html" title="Français"> fr </a></p>
+</div>
+
+
+ <p>Ce document complémente la
+ <a href="../mod/mod_rewrite.html">documentation de référence</a> du
+ module <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>. Il décrit les différentes
+ manières d'utiliser le module d'Apache <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>
+ pour résoudre les problèmes d'URLs typiques auxquels sont souvent
+ confrontés les webmasters. Nous fournissons une description
+ détaillée de la résolution de chaque problème par la configuration
+ d'un jeu de règles de réécriture.</p>
+
+ <div class="warning">ATTENTION: il pourra s'avérer nécessaire de
+ modifier les exemples en fonction de la
+ configuration de votre serveur, par exemple en ajoutant le drapeau
+ <code>[PT]</code> si les modules <code class="module"><a href="../mod/mod_alias.html">mod_alias</a></code> et
+ <code class="module"><a href="../mod/mod_userdir.html">mod_userdir</a></code> sont utilisés, etc... Les jeux de
+ règles devront également être adaptés pour passer d'un contexte de
+ serveur à un contexte de répertoire (fichiers
+ <code>.htaccess</code>). Essayez de toujours bien comprendre ce que
+ fait un jeu de règles avant de l'utiliser, ce qui pourra vous éviter
+ bien des problèmes.</div>
+
+ </div>
+<div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#cluster">Accès à une grappe de serveurs via un espace d'adressage
+ compatible</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#structuredhomedirs">Répertoires utilisateurs structurés</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#filereorg">Réorganisation du système de fichiers</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#redirect404">Rediriger les URLs erronées vers un autre serveur Web</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#archive-access-multiplexer">Multiplexeur d'accès aux archives</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#browser-dependent-content">Contenu dépendant du navigateur</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#dynamic-mirror">Miroir dynamique</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#reverse-dynamic-mirror">Miroir dynamique inverse</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#retrieve-missing-data">Récupérer des données manquantes depuis l'Intranet</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#load-balancing">Répartition de charge</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#new-mime-type">Nouveau type MIME, nouveau service</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#on-the-fly-content">Régéneration de contenu à la volée</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#autorefresh">Actualisation automatique d'un document</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#mass-virtual-hosting">Hébergement virtuel de masse</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#host-deny">Interdiction d'hôtes</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#proxy-deny">Interdiction du mandataire</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#special-authentication">Variante particulière d'authentification</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#referer-deflector">Redirection basée sur le référent</a></li>
+</ul><h3>Voir aussi</h3><ul class="seealso"><li><a href="../mod/mod_rewrite.html">Documentation du
+module</a></li><li><a href="rewrite_intro.html">Introduction à
+mod_rewrite</a></li><li><a href="rewrite_guide.html">Guide de réécriture - exemples
+utiles</a></li><li><a href="rewrite_tech.html">Détails techniques</a></li></ul></div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="cluster" id="cluster">Accès à une grappe de serveurs via un espace d'adressage
+ compatible</a></h2>
+
+
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Comment créer un espace d'adressage homogène et compatible
+ avec
+ tous les serveurs WWW d'une grappe de serveurs d'un intranet ?
+ C'est à dire que toutes les URLs (par définition
+ locales à un
+ serveur et dépendant donc de celui-ci) deviennent
+ véritablement <em>indépendantes</em> du serveur ! Nous voulons
+ disposer, pour accéder à l'espace de nommage WWW, d'un seul
+ espace d'adressage compatible : aucune URL ne
+ doit inclure d'information quelconque à propos du serveur
+ cible physique. La grappe de serveurs doit elle-même nous
+ diriger automatiquement vers le bon serveur cible physique,
+ selon les besoins, et ceci de manière transparente.</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>Tout d'abord, la connaissance des serveurs cibles est issue
+ de tables de correspondances externes (distribuées) qui
+ contiennent des informations sur la localisation de nos
+ utilisateurs, groupes et entités. Elles se présentent sous la
+ forme :</p>
+
+<div class="example"><pre>
+utilisateur1 serveur_utilisateur1
+utilisateur2 serveur_utilisateur2
+: :
+</pre></div>
+
+ <p>On les enregistre sous forme de fichiers
+ <code>map.xxx-vers-serveur</code>. On doit ensuite faire
+ rediriger à tous les serveurs les URLs de la forme :</p>
+
+<div class="example"><pre>
+/u/utilisateur/chemin
+/g/groupe/chemin
+/e/entité/chemin
+</pre></div>
+
+ <p>vers</p>
+
+<div class="example"><pre>
+http://serveur-physique/u/utilisateur/chemin
+http://serveur-physique/g/groupe/chemin
+http://serveur-physique/e/entité/chemin
+</pre></div>
+
+ <p>si il n'est pas nécessaire que chaque chemin d'URL être valide sur chaque
+ serveur. Le jeu
+ de règles suivant le fait pour nous à l'aide des fichiers de
+ correspondance (en supposant que serveur0 soit un serveur par
+ défaut qui sera choisi si l'utilisateur ne possède aucune
+ entrée dans la table) :</p>
+
+<div class="example"><pre>
+RewriteEngine on
+
+RewriteMap utilisateur-vers-serveur txt:/chemin/vers/map.utilisateur-vers-serveur
+RewriteMap groupe-vers-serveur txt:/chemin/vers/map.groupe-vers-serveur
+RewriteMap entité-vers-serveur txt:/chemin/vers/map.entité-vers-serveur
+
+RewriteRule ^/u/<strong>([^/]+)</strong>/?(.*)
+http://<strong>${utilisateur-vers-serveur:$1|serveur0}</strong>/u/$1/$2
+RewriteRule ^/g/<strong>([^/]+)</strong>/?(.*)
+http://<strong>${groupe-vers-serveur:$1|serveur0}</strong>/g/$1/$2
+RewriteRule ^/e/<strong>([^/]+)</strong>/?(.*)
+http://<strong>${entité-vers-serveur:$1|serveur0}</strong>/e/$1/$2
+
+RewriteRule ^/([uge])/([^/]+)/?$ /$1/$2/.www/
+RewriteRule ^/([uge])/([^/]+)/([^.]+.+) /$1/$2/.www/$3\
+</pre></div>
+ </dd>
+ </dl>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="structuredhomedirs" id="structuredhomedirs">Répertoires utilisateurs structurés</a></h2>
+
+
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Certains sites possédant des milliers d'utilisateurs
+ organisent les répertoires home de manière
+ structurée, <em>c'est à dire</em> que chaque répertoire home
+ se situe dans un sous-répertoire dont le nom commence (par
+ exemple) par le premier caractère du nom de l'utilisateur.
+ Ainsi, <code>/~foo/chemin</code> est dans
+ <code>/home/<strong>f</strong>/foo/.www/chemin</code>, tandis
+ que <code>/~bar/chemin</code> est dans
+ <code>/home/<strong>b</strong>/bar/.www/chemin</code>.</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>Le jeu de règles suivant permet de développer les URLs avec
+ tilde selon la représentation ci-dessus.</p>
+
+<div class="example"><pre>
+RewriteEngine on
+RewriteRule ^/~(<strong>([a-z])</strong>[a-z0-9]+)(.*) /home/<strong>$2</strong>/$1/.www$3
+</pre></div>
+ </dd>
+ </dl>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="filereorg" id="filereorg">Réorganisation du système de fichiers</a></h2>
+
+
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Voici un cas d'espèce : une application très efficace qui
+ fait un usage intensif de règles <code>RewriteRule</code>
+ dans le contexte du répertoire pour présenter un aspect
+ compréhensible sur le Web sans modifier la structure des
+ données.
+ Les coulisses de l'affaire : <strong><em>net.sw</em></strong>
+ rassemble mes archives de paquetages de logiciels Unix
+ librement accessibles, que j'ai commencé à collectionner en
+ 1992. Pour moi, c'est un passe-temps, mais aussi un travail,
+ car alors que j'étudie la science informatique, j'ai aussi
+ travaillé depuis de nombreuses années comme administrateur
+ système et réseau à mes heures perdues. Chaque semaine j'ai
+ besoin de tel ou tel logiciel, et j'ai donc créé une
+ arborescence très ramifiée de répertoires où je stocke les
+ paquetages :</p>
+
+<div class="example"><pre>
+drwxrwxr-x 2 netsw users 512 Aug 3 18:39 Audio/
+drwxrwxr-x 2 netsw users 512 Jul 9 14:37 Benchmark/
+drwxrwxr-x 12 netsw users 512 Jul 9 00:34 Crypto/
+drwxrwxr-x 5 netsw users 512 Jul 9 00:41 Database/
+drwxrwxr-x 4 netsw users 512 Jul 30 19:25 Dicts/
+drwxrwxr-x 10 netsw users 512 Jul 9 01:54 Graphic/
+drwxrwxr-x 5 netsw users 512 Jul 9 01:58 Hackers/
+drwxrwxr-x 8 netsw users 512 Jul 9 03:19 InfoSys/
+drwxrwxr-x 3 netsw users 512 Jul 9 03:21 Math/
+drwxrwxr-x 3 netsw users 512 Jul 9 03:24 Misc/
+drwxrwxr-x 9 netsw users 512 Aug 1 16:33 Network/
+drwxrwxr-x 2 netsw users 512 Jul 9 05:53 Office/
+drwxrwxr-x 7 netsw users 512 Jul 9 09:24 SoftEng/
+drwxrwxr-x 7 netsw users 512 Jul 9 12:17 System/
+drwxrwxr-x 12 netsw users 512 Aug 3 20:15 Typesetting/
+drwxrwxr-x 10 netsw users 512 Jul 9 14:08 X11/
+</pre></div>
+
+ <p>J'ai décidé en 1996 de rendre cette archive disponible pour
+ le monde via une interface web agréable. "Agréable" signifie
+ que je voulais vous offrir une interface où vous pourriez
+ naviguer directement à travers la hiérarchie des archives.
+ Mais "agréable" signifie aussi que je ne voulais rien changer
+ dans cette hiérarchie - même pas en ajoutant queques scripts
+ CGI à son sommet. Pourquoi ? Parceque j'avais prévu de rendre
+ ultérieurement la structure ci-dessus accessible aussi via
+ FTP, et je ne voulais pas voir de fichiers CGI ou Web à ce
+ niveau.</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>La solution comporte deux parties : la première consiste en
+ un ensemble de scripts CGI qui créent toutes les pages à tous
+ les niveaux de répertoires à la volée. Je les ai placés dans
+ <code>/e/netsw/.www/</code> comme suit :</p>
+
+<div class="example"><pre>
+-rw-r--r-- 1 netsw users 1318 Aug 1 18:10 .wwwacl
+drwxr-xr-x 18 netsw users 512 Aug 5 15:51 DATA/
+-rw-rw-rw- 1 netsw users 372982 Aug 5 16:35 LOGFILE
+-rw-r--r-- 1 netsw users 659 Aug 4 09:27 TODO
+-rw-r--r-- 1 netsw users 5697 Aug 1 18:01 netsw-about.html
+-rwxr-xr-x 1 netsw users 579 Aug 2 10:33 netsw-access.pl
+-rwxr-xr-x 1 netsw users 1532 Aug 1 17:35 netsw-changes.cgi
+-rwxr-xr-x 1 netsw users 2866 Aug 5 14:49 netsw-home.cgi
+drwxr-xr-x 2 netsw users 512 Jul 8 23:47 netsw-img/
+-rwxr-xr-x 1 netsw users 24050 Aug 5 15:49 netsw-lsdir.cgi
+-rwxr-xr-x 1 netsw users 1589 Aug 3 18:43 netsw-search.cgi
+-rwxr-xr-x 1 netsw users 1885 Aug 1 17:41 netsw-tree.cgi
+-rw-r--r-- 1 netsw users 234 Jul 30 16:35 netsw-unlimit.lst
+</pre></div>
+
+ <p>Le sous-répertoire <code>DATA/</code> contient la structure
+ de répertoires proprement dite mentionnée plus haut, <em>c'est
+ à dire</em> les véritables ressources
+ <strong><em>net.sw</em></strong> et est mis à jour
+ automatiquement via <code>rdist</code> à intervalles de temps
+ réguliers. Reste la seconde partie du problème : comment
+ relier ces deux structures selon une arborescence d'URL
+ facile d'accès ? Il nous faut cacher le répertoire
+ <code>DATA/</code> à l'utilisateur durant l'exécution des
+ scripts CGI appropriés aux différentes URLs. Voici comment :
+ tout d'abord, j'ajoute ces deux règles dans le fichier de
+ configuration du répertoire racine <code class="directive"><a href="../mod/core.html#documentroot">DocumentRoot</a></code> du serveur afin de
+ réécrire le chemin d'URL public <code>/net.sw/</code> vers le
+ chemin interne <code>/e/netsw</code> :</p>
+
+<div class="example"><pre>
+RewriteRule ^net.sw$ net.sw/ [R]
+RewriteRule ^net.sw/(.*)$ e/netsw/$1
+</pre></div>
+
+ <p>La première règle concerne les requêtes qui ne comportent
+ pas de slash de fin ! C'est la seconde règle qui fait le
+ véritable travail. Et maintenant vient la super configuration
+ qui se trouve dans le fichier de configuration de répertoire
+ <code>/e/netsw/.www/.wwwacl</code> :</p>
+
+<div class="example"><pre>
+Options ExecCGI FollowSymLinks Includes MultiViews
+
+RewriteEngine on
+
+# l'accès s'effectue via le préfixe /net.sw/
+RewriteBase /net.sw/
+
+# tout d'abord, on réécrit le répertoire racine vers
+# le script CGI qui lui est associé
+RewriteRule ^$ netsw-home.cgi [L]
+RewriteRule ^index\.html$ netsw-home.cgi [L]
+
+# on supprime les sous-répertoires lorsque
+# le navigateur nous atteint depuis des pages de répertoire
+RewriteRule ^.+/(netsw-[^/]+/.+)$ $1 [L]
+
+# on stoppe maintenant la réécriture pour les fichiers locaux
+RewriteRule ^netsw-home\.cgi.* - [L]
+RewriteRule ^netsw-changes\.cgi.* - [L]
+RewriteRule ^netsw-search\.cgi.* - [L]
+RewriteRule ^netsw-tree\.cgi$ - [L]
+RewriteRule ^netsw-about\.html$ - [L]
+RewriteRule ^netsw-img/.*$ - [L]
+
+# ce qui reste est un sous-répertoire qui peut être traité
+# par un autre script CGI
+RewriteRule !^netsw-lsdir\.cgi.* - [C]
+RewriteRule (.*) netsw-lsdir.cgi/$1
+</pre></div>
+
+ <p>Quelques indices pour l'interprétation :</p>
+
+ <ol>
+ <li>Remarquez le drapeau <code>L</code> (last) et l'absence
+ de chaîne de substitution ('<code>-</code>') dans la
+ quatrième partie.</li>
+
+ <li>Remarquez le caractère <code>!</code> (not) et le
+ drapeau <code>C</code> (chain) dans la première règle de la
+ dernière partie.</li>
+
+ <li>Remarquez le modèle qui correspond à tout dans la
+ dernière règle.</li>
+ </ol>
+ </dd>
+ </dl>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="redirect404" id="redirect404">Rediriger les URLs erronées vers un autre serveur Web</a></h2>
+
+
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Une question typique de la FAQ à propos de la réécriture
+ revient souvent : comment rediriger vers un serveur B les
+ requêtes qui échouent sur un serveur A ? On s'acquitte en
+ général de cette tâche via des scripts CGI <code class="directive"><a href="../mod/core.html#errordocument">ErrorDocument</a></code> en Perl, mais il
+ existe aussi une solution avec <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>.
+ Notez cependant que les performances sont moindres qu'avec
+ l'utilisation d'un script CGI <code class="directive"><a href="../mod/core.html#errordocument">ErrorDocument</a></code> !</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>La première solution possède des performances supérieures
+ mais moins de souplesse, et est moins sure :</p>
+
+<div class="example"><pre>
+RewriteEngine on
+RewriteCond %{DOCUMENT_ROOT/%{REQUEST_URI} <strong>!-f</strong>
+RewriteRule ^(.+) http://<strong>serveurB</strong>.dom/$1
+</pre></div>
+
+ <p>Le problème réside dans le fait que seules les pages
+ situées dans la racine <code class="directive"><a href="../mod/core.html#documentroot">DocumentRoot</a></code> seront redirigées. Mais
+ même si vous pouvez ajouter des conditions supplémentaires (par
+ exemple pour traiter aussi les répertoires home, etc...), il
+ existe une meilleure solution :</p>
+
+<div class="example"><pre>
+RewriteEngine on
+RewriteCond %{REQUEST_URI} <strong>!-U</strong>
+RewriteRule ^(.+) http://<strong>serveurB</strong>.dom/$1
+</pre></div>
+reprendre ici
+ <p>On utilise ici la fonctionnalité de prévision des URLs
+ futures de <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>. Et cette solution
+ fonctionne pour tous les types d'URLs et de manière sûre. Par
+ contre, cette méthode a un impact sur les performances du
+ serveur web, car chaque requête entraîne le traitement d'une
+ sous-requête interne supplémentaire. Par conséquent, vous
+ pouvez l'utiliser si votre serveur web s'exécute sur un CPU
+ puissant. Dans le cas d'une machine plus lente, utilisez la
+ première approche, ou mieux, un script CGI <code class="directive"><a href="../mod/core.html#errordocument">ErrorDocument</a></code>.</p>
+ </dd>
+ </dl>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="archive-access-multiplexer" id="archive-access-multiplexer">Multiplexeur d'accès aux archives</a></h2>
+
+
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Connaissez-vous la grande archive CPAN (Comprehensive Perl Archive
+ Network) située à <a href="http://www.perl.com/CPAN">http://www.perl.com/CPAN</a> ?
+ CPAN redirige automatiquement les navigateurs vers un des
+ nombreux serveurs FTP répartis à travers le monde
+ (généralement un serveur assez proche du client) ; chaque
+ serveur héberge l'intégralité d'un miroir CPAN. Il s'agit ni
+ plus ni moins qu'un service d'accès FTP multiplexé. Alors que
+ le fonctionnement de l'archive CPAN repose sur des scripts
+ CGI, comment implémenter une approche similaire avec
+ <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> ?</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>Premièrement, remarquons que depuis la version 3.0.0,
+ <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> accepte aussi le préfixe
+ "<code>ftp:</code>" dans les redirections. Et deuxièmement,
+ l'approximation de la localisation peut être effectuée par une
+ table de correspondances <code class="directive"><a href="../mod/mod_rewrite.html#rewritemap">RewriteMap</a></code>, en se basant sur
+ la racine du domaine du client. Un jeu de règles chaînées
+ astucieux nous permet d'utiliser cette racine du domaine comme
+ clé de recherche dans notre table de correspondances de
+ multiplexage.</p>
+
+<div class="example"><pre>
+RewriteEngine on
+RewriteMap multiplex txt:/chemin/vers/map.cxan
+RewriteRule ^/CxAN/(.*) %{REMOTE_HOST}::$1 [C]
+RewriteRule ^.+\.<strong>([a-zA-Z]+)</strong>::(.*)$
+${multiplex:<strong>$1</strong>|ftp.défaut.dom}$2 [R,L]
+</pre></div>
+
+<div class="example"><pre>
+##
+## map.cxan -- Multiplexing Map for CxAN%{DOCUMENT_ROOT/%{REQUEST_URI}
+##
+
+de ftp://ftp.cxan.de/CxAN/
+uk ftp://ftp.cxan.uk/CxAN/
+com ftp://ftp.cxan.com/CxAN/
+ :
+##EOF##
+</pre></div>
+ </dd>
+ </dl>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="browser-dependent-content" id="browser-dependent-content">Contenu dépendant du navigateur</a></h2>
+
+
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Il est parfois nécessaire, au moins pour les pages
+ principales, de fournir un contenu optimum adapté à chaque
+ type de navigateur, c'est à dire que l'on doit
+ fournir une version pour les navigateurs courants, une version
+ différente pour les navigateurs en mode texte du style de
+ Lynx, et une autre pour les autres navigateurs.</p>
+ </dd>
+
+ <dt>Solution :</dt>%{DOCUMENT_ROOT/%{REQUEST_URI}
+
+ <dd>
+ <p>On ne peut pas utiliser la négociation de contenu car les
+ navigateurs ne fournissent pas leur type dans cette forme.
+ Nous devons nous baser sur l'en-tête HTTP "User-Agent". La
+ configuration ci-dessous effectue les actions suivantes : si
+ l'en-tête HTTP "User-Agent" commence par "Mozilla/3", la page
+ <code>foo.html</code> est réécrite en <code>foo.NS.html</code>
+ et la réécriture s'arrête. Si le navigateur est "Lynx" ou
+ "Mozilla" version 1 ou 2, la page
+ <code>foo.html</code> est réécrite en
+ <code>foo.20.html</code>. Tous les autres navigateurs
+ reçoivent la page <code>foo.32.html</code>. Voici le jeu de
+ règles :</p>
+
+<div class="example"><pre>
+RewriteCond %{HTTP_USER_AGENT} ^<strong>Mozilla/3</strong>.*
+RewriteRule ^foo\.html$ foo.<strong>NS</strong>.html [<strong>L</strong>]
+
+RewriteCond %{HTTP_USER_AGENT} ^<strong>Lynx/</strong>.* [OR]
+RewriteCond %{HTTP_USER_AGENT} ^<strong>Mozilla/[12]</strong>.*
+RewriteRule ^foo\.html$ foo.<strong>20</strong>.html [<strong>L</strong>]
+
+RewriteRule ^foo\.html$ foo.<strong>32</strong>.html [<strong>L</strong>]
+</pre></div>
+ </dd>
+ </dl>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="dynamic-mirror" id="dynamic-mirror">Miroir dynamique</a></h2>
+
+
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Supposons que nous voulions intégrer dans notre espace de
+ nommage de belles pages web situées sur un serveur distant.
+ Dans le cas d'un serveur FTP, nous aurions utilisé le
+ programme <code>mirror</code> qui maintient vraiment une copie
+ des données distantes mise à jour explicitement sur le serveur
+ local. Pour un serveur web, nous pourrions utiliser le
+ programme <code>webcopy</code> qui utilise le protocole HTTP.
+ Ces deux techniques présentent cependant un
+ inconvénient majeur : la copie locale n'est véritablement à
+ jour qu'au moment où nous avons lancé le programme. Plutôt qu'
+ un miroir statique devant être défini explicitement, il serait
+ préférable d'avoir un miroir dynamique dont le contenu serait
+ mis à jour automatiquement, à la demande, sur le(s) serveur(s)
+ distant(s).</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>Pour y parvenir, on fait
+ correspondre la page web ou même l'ensemble du
+ répertoire web distants à notre espace de nommage en utilisant
+ la fonctionnalité <dfn>Mandataire</dfn> (drapeau
+ <code>[P]</code> ou <code>[proxy]</code>) :</p>
+
+<div class="example"><pre>
+RewriteEngine on
+RewriteBase /~quux/
+RewriteRule ^<strong>page-convoitée/</strong>(.*)$ <strong>http://www.tstimpreso.com/page-convoitée/</strong>$1 [<strong>P</strong>]
+</pre></div>
+
+<div class="example"><pre>
+RewriteEngine on
+RewriteBase /~quux/
+RewriteRule ^<strong>usa-news\.html</strong>$ <strong>http://www.quux-corp.com/news/index.html</strong> [<strong>P</strong>]
+</pre></div>
+ </dd>
+ </dl>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="reverse-dynamic-mirror" id="reverse-dynamic-mirror">Miroir dynamique inverse</a></h2>
+
+
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>...</dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+<div class="example"><pre>
+RewriteEngine on
+RewriteCond /miroir/du/site-distant/$1 -U
+RewriteRule ^http://www\.site-distant\.com/(.*)$ /miroir/du/site-distant/$1
+</pre></div>
+ </dd>
+ </dl>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="retrieve-missing-data" id="retrieve-missing-data">Récupérer des données manquantes depuis l'Intranet</a></h2>
+
+
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>C'est une méthode astucieuse permettant de faire
+ fonctionner virtuellement un serveur web d'entreprise
+ (<code>www.quux-corp.dom</code>) sur
+ l'Internet (extérieur à l'entreprise), tout en maintenant et
+ conservant dans la réalité ses données sur un serveur web
+ (<code>www2.quux-corp.dom</code>) de l'Intranet (interne à
+ l'entreprise) protégé par un pare-feu. L'astuce consiste, sur
+ le serveur web externe, à récupérer à la volée sur le serveur interne
+ les données demandées.</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>Tout d'abord, nous devons nous assurer que notre pare-feu
+ protège bien le serveur web interne, et que seul le serveur
+ web externe est autorisé à y récupérer des données. Dans le
+ cas d'un filtrage par paquets, nous pourrions par exemple
+ définir un jeu de règles du pare-feu du style :</p>
+
+<div class="example"><pre>
+<strong>ALLOW</strong> serveur www.quux-corp.dom Port >1024 -->
+serveur www2.quux-corp.dom Port <strong>80</strong>
+<strong>DENY</strong> serveur * Port * -->
+serveur www2.quux-corp.dom Port <strong>80</strong>
+</pre></div>
+
+ <p>Il vous suffit d'adapter ces règles à la syntaxe de votre
+ pare-feu. Nous pouvons maintenant définir les règles de
+ <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> qui serviront à récupérer les
+ données manquantes en arrière-plan via la fonctionnalité de
+ mandataire :</p>
+
+<div class="example"><pre>
+RewriteRule ^/~([^/]+)/?(.*) /home/$1/.www/$2 [C]
+# L'utilisation de REQUEST_FILENAME ci dessous est correcte dans cet
+# exemple de contexte au niveau serveur car la règle qui fait référence
+# à REQUEST_FILENAME est chaînée à une règle qui définit
+# REQUEST_FILENAME.
+RewriteCond %{REQUEST_FILENAME} <strong>!-f</strong>
+RewriteCond %{REQUEST_FILENAME} <strong>!-d</strong>
+RewriteRule ^/home/([^/]+)/.www/?(.*) http://<strong>www2</strong>.quux-corp.dom/~$1/pub/$2 [<strong>P</strong>]
+</pre></div>
+ </dd>
+ </dl>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="load-balancing" id="load-balancing">Répartition de charge</a></h2>
+
+
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Supposons que nous voulions répartir la charge du trafic
+ vers <code>www.example.com</code> entre les serveurs
+ <code>www[0-5].example.com</code> (un total de 6 serveurs).
+ Comment y parvenir ?</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>Il existe de nombreuses solutions à ce problème. Nous
+ décrirons tout d'abord une variante assez connue basée sur
+ DNS, puis une autre basée sur <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>
+ :</p>
+
+ <ol>
+ <li>
+ <strong>Round-Robin (tourniquet) DNS</strong>
+
+ <p>La méthode de répartition de charge la plus simple
+ consiste à utiliser le "DNS round-robin"
+ (rotation d'adresses) de
+ <code>BIND</code>. Vous devez seulement enregistrer les
+ serveurs <code>www[0-9].example.com</code> de manière
+ habituelle dans votre DNS à l'aide d'enregistrements de
+ type A (adresse), comme suit :</p>
+
+<div class="example"><pre>
+www0 IN A 1.2.3.1
+www1 IN A 1.2.3.2
+www2 IN A 1.2.3.3
+www3 IN A 1.2.3.4
+www4 IN A 1.2.3.5
+www5 IN A 1.2.3.6
+</pre></div>
+
+ <p>Puis vous ajoutez les entrées suivantes :</p>
+
+<div class="example"><pre>
+www IN A 1.2.3.1
+www IN A 1.2.3.2
+www IN A 1.2.3.3
+www IN A 1.2.3.4
+www IN A 1.2.3.5
+</pre></div>
+
+ <p>Maintenant, lors de la résolution de
+ <code>www.example.com</code>, <code>BIND</code> renvoie
+ <code>www0-www5</code> - mais selon une permutation
+ différente à chaque fois. De cette façon, les clients sont
+ répartis entre les différents serveurs. Notez cependant
+ que cette méthode de répartition de charge n'est pas
+ parfaite, car les résolutions DNS sont mises en cache par
+ les clients et les autres serveurs DNS du réseau, si
+ bien que lorsqu'un client s'est vu résoudre
+ <code>www.example.com</code> en un des
+ <code>wwwN.example.com</code>, toutes ses requêtes ultérieures
+ continueront d'aller vers la même adresse IP (et donc le
+ même serveur), au lieu d'être réparties entre les autres
+ serveurs. Le résultat est cependant globalement
+ satisfaisant car les requêtes sont réparties
+ collectivement entre chacun des serveurs web.</p>
+ </li>
+
+ <li>
+ <strong>Répartition de charge basée sur DNS</strong>
+
+ <p>Une méthode de répartition de charge sophistiquée basée
+ sur DNS consiste à utiliser le programme
+ <code>lbnamed</code> que l'on peut trouver à <a href="http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html">
+ http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html</a>.
+ Associé à des outils auxiliaires, il s'agit d'un programme
+ en Perl 5 qui permet d'effectuer une véritable répartition
+ de charge basée sur DNS.</p>
+ </li>
+
+ <li>
+ <strong>Round-Robin basé sur la fonctionnalité de
+ mandataire</strong>
+
+ <p>Dans cette variante, nous utilisons
+ <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> et sa fonctionnalité de
+ mandataire. Tout d'abord, nous définissons
+ <code>www0.example.com</code> comme un autre nom de
+ <code>www.example.com</code> en ajoutant l'entrée</p>
+
+<div class="example"><pre>
+www IN CNAME www0.example.com.
+</pre></div>
+
+ <p>dans le DNS. Puis nous définissons
+ <code>www0.example.com</code> comme serveur mandataire
+ seulement, c'est à dire que nous configurons cette machine
+ de telle sorte que toutes les URLs qui lui arrivent soient
+ simplement transmises, via le mandataire interne, vers un
+ des 5 autres serveurs (<code>www1-www5</code>). Pour y
+ parvenir, nous définissons tout d'abord un jeu de règles
+ qui contacte un script de répartition de charge
+ <code>lb.pl</code> pour toutes les URLs.</p>
+
+<div class="example"><pre>
+RewriteEngine on
+RewriteMap lb prg:/chemin/vers/lb.pl
+RewriteRule ^/(.+)$ ${lb:$1} [P,L]
+</pre></div>
+
+ <p>Puis nous écrivons <code>lb.pl</code> :</p>
+
+<div class="example"><pre>
+#!/chemin/vers/perl
+##
+## lb.pl -- script de répartition de charge
+##
+
+$| = 1;
+
+$name = "www"; # la base du nom du serveur
+$first = 1; # le premier serveur (pas 0 ici, car 0 correspond à
+ # moi-même)
+$last = 5; # le dernier serveur du tourniquet
+$domain = "foo.dom"; # le nom de domaine
+
+$cnt = 0;
+while (<STDIN>) {
+ $cnt = (($cnt+1) % ($last+1-$first));
+ $server = sprintf("%s%d.%s", $name, $cnt+$first, $domain);
+ print "http://$server/$_";
+}
+
+##EOF##
+</pre></div>
+
+ <div class="note">Une dernière remarque : à quoi cela sert-il ?
+ <code>www0.example.com</code>, quant à lui, n'est-il pas
+ toujours surchargé ? La réponse est oui, il est surchargé,
+ mais seulement avec des requêtes de mandataire ! Tous les
+ traitements SSI, CGI, ePerl, etc... sont entièrement
+ effectués sur les autres machines. Ceci peut fonctionner
+ correctement pour un site complexe. Le plus grand risque
+ réside ici dans le fait que www0 est un passage obligé et
+ que s'il est hors service, les autres serveurs deviennent
+ inaccessibles.</div>
+ </li>
+
+ <li>
+ <strong>Répartiteur de charge dédié</strong>
+
+ <p>Il existe aussi des solutions plus sophistiquées.
+ Cisco, F5, et de nombreuses autres sociétés proposent
+ des répartiteurs de charge matériels (utilisés en général
+ en mode doublé à des fins de redondance), qui offrent une
+ répartition de charge sophistiquée et des fonctionnalités
+ de passage automatique en mode de fonctionnement par défaut
+ en cas de problème. Cependant, des solutions logicielles
+ offrent aussi des fonctionnalités similaires avec du
+ matériel standard. Si vos besoins correspondent et si vous
+ êtes assez riche, vous pouvez envisager ces solutions. La
+ <a href="http://vegan.net/lb/">liste de diffusion lb-l</a>
+ est un bon point de départ pour vos recherches.</p>
+ </li>
+ </ol>
+ </dd>
+ </dl>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="new-mime-type" id="new-mime-type">Nouveau type MIME, nouveau service</a></h2>
+
+
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>On trouve de nombreux programmes CGI attractifs sur le
+ réseau. Mais leur emploi est souvent rébarbatif, si bien que
+ de nombreux webmasters ne les utilisent pas. Même la
+ fonctionnalité de gestionnaire Action d'Apache pour les types
+ MIME ne convient que lorsque les programmes CGI ne nécessitent
+ pas d'URLs spéciales (réellement <code>PATH_INFO</code> et
+ <code>QUERY_STRINGS</code>) en entrée. Tout d'abord,
+ définissons un nouveau type de fichier ayant pour extension
+ <code>.scgi</code> (pour CGI sécurisé) qui sera associé pour
+ traitement au programme populaire <code>cgiwrap</code>. Le
+ problème est le suivant : par exemple, si on utilise un style
+ d'URL bien défini (voir ci-dessus), un fichier situé dans le
+ répertoire home de l'utilisateur pourra correspondre à l'URL
+ <code>/u/user/foo/bar.scgi</code>. Mais <code>cgiwrap</code>
+ nécessite des URLs de la forme
+ <code>/~user/foo/bar.scgi/</code>. La règle suivante apporte
+ la solution :</p>
+
+<div class="example"><pre>
+RewriteRule ^/[uge]/<strong>([^/]+)</strong>/\.www/(.+)\.scgi(.*) ...
+... /interne/cgi/utilisateur/cgiwrap/~<strong>$1</strong>/$2.scgi$3 [NS,<strong>T=application/x-http-cgi</strong>]
+</pre></div>
+
+ <p>Ou considérons ces autres programmes attractifs :
+ <code>wwwlog</code> (qui affiche le journal des accès
+ <code>access.log</code> pour un sous répertoire correspondant
+ à une URL) et <code>wwwidx</code> (qui exécute Glimpse sur un
+ sous répertoire correspondant à une URL). Nous devons fournir
+ l'URL correspondante à ces programmes afin qu'ils sachent sur
+ quel répertoire ils doivent agir. Mais c'est en général
+ compliqué, car ils peuvent être appelés à nouveau
+ par la forme d'URL alternative, c'est à dire que typiquement,
+ nous exécuterions le programme <code>swwidx</code> depuis
+ <code>/u/user/foo/</code> via un hyperlien vers</p>
+
+<div class="example"><pre>
+/internal/cgi/user/swwidx?i=/u/user/foo/
+</pre></div>
+
+ <p>ce qui n'est pas satisfaisant, car nous devons expliciter
+ <strong>à la fois</strong> la localisation du répertoire
+ <strong>et</strong> la localisation du programme CGI dans
+ l'hyperlien. Si nous devons nous réorganiser, il nous faudra
+ beaucoup de temps pour modifier tous les hyperliens.</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>La solution consiste ici à fournir un nouveau format d'URL
+ qui redirige automatiquement vers la requête CGI appropriée.
+ Pour cela, on définit les règles suivantes :</p>
+
+<div class="example"><pre>
+RewriteRule ^/([uge])/([^/]+)(/?.*)/\* /interne/cgi/utilisateur/wwwidx?i=/$1/$2$3/
+RewriteRule ^/([uge])/([^/]+)(/?.*):log /interne/cgi/utilisateur/wwwlog?f=/$1/$2$3
+</pre></div>
+
+ <p>Et maintenant l'hyperlien qui renvoie vers
+ <code>/u/user/foo/</code> se réduit à</p>
+
+<div class="example"><pre>
+HREF="*"
+</pre></div>
+
+ <p>qui est automatiquement transformé en interne en</p>
+
+<div class="example"><pre>
+/internal/cgi/user/wwwidx?i=/u/user/foo/
+</pre></div>
+
+ <p>Une approche similaire permet d'invoquer le programme CGI
+ du journal des accès lorsque l'hyperlien <code>:log</code> est
+ utilisé.</p>
+ </dd>
+ </dl>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="on-the-fly-content" id="on-the-fly-content">Régéneration de contenu à la volée</a></h2>
+
+
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Voici une fonctionnalité vraiment ésotérique : des pages
+ générées dynamiquement mais servies statiquement, c'est à
+ dire que les pages doivent être servies comme des pages
+ purement statiques (lues depuis le système de fichiers et
+ servies en l'état), mais doivent être générées dynamiquement
+ par le serveur web si elles sont absentes. Ainsi, vous pouvez
+ avoir des pages générées par CGI qui sont servies statiquement
+ à moins qu'un administrateur (ou une tâche de
+ <code>cron</code>) ne supprime les
+ contenus statiques. Les contenus sont ensuite actualisés.</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ A cet effet, on utilise le jeu de règles suivant :
+
+<div class="example"><pre>
+# Cet exemple n'est valable que dans un contexte de répertoire
+RewriteCond %{REQUEST_FILENAME} <strong>!-s</strong>
+RewriteRule ^page\.<strong>html</strong>$ page.<strong>cgi</strong> [T=application/x-httpd-cgi,L]
+</pre></div>
+
+ <p>Ainsi, une requête pour <code>page.html</code> entraîne
+ l'exécution interne de la page <code>page.cgi</code>
+ correspondante si <code>page.html</code> n'existe pas
+ ou possède une taille de fichier nulle. L'astuce réside ici
+ dans le fait que <code>page.cgi</code> est un script CGI
+ qui (en plus de <code>STDOUT</code>) écrit sa sortie dans le
+ fichier <code>page.html</code>. Une fois le script exécuté, le
+ serveur sert la page <code>page.html</code> fraîchement
+ générée. Si le webmaster
+ veut actualiser les contenus, il lui suffit de supprimer le
+ fichier <code>page.html</code> (le plus souvent via une tâche
+ de <code>cron</code>).</p>
+ </dd>
+ </dl>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="autorefresh" id="autorefresh">Actualisation automatique d'un document</a></h2>
+
+
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Lorsque nous créons une page web complexe, ne serait-il pas
+ souhaitable que le navigateur web actualise automatiquement la
+ page chaque fois que nous en sauvegardons une nouvelle version
+ à partir de notre éditeur ? Impossible ?</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>Non ! Nous allons pour cela combiner la fonctionnalité MIME
+ multipart, la fonctionnalité NPH du serveur web et la
+ puissance de <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> pour la manipulation
+ d'URLs. Tout d'abord, nous définissons une nouvelle
+ fonctionnalité pour les URLs : l'ajout de
+ <code>:refresh</code> à toute URL fait que la 'page' est
+ actualisée chaque fois que la ressource est mise à jour dans
+ le système de fichiers.</p>
+
+<div class="example"><pre>
+RewriteRule ^(/[uge]/[^/]+/?.*):refresh /interne/cgi/apache/nph-refresh?f=$1
+</pre></div>
+
+ <p>Nous appelons maintenant cette URL</p>
+
+<div class="example"><pre>
+/u/foo/bar/page.html:refresh
+</pre></div>
+
+ <p>ce qui entraîne en interne l'invocation de l'URL</p>
+
+<div class="example"><pre>
+/interne/cgi/apache/nph-refresh?f=/u/foo/bar/page.html
+</pre></div>
+
+ <p>Il ne reste plus qu'à écrire le script CGI. Bien que l'on
+ écrive habituellement dans ces cas "laissé à la charge du
+ lecteur à titre d'exercice", ;-) je vous l'offre, aussi.</p>
+
+<div class="example"><pre>
+#!/sw/bin/perl
+##
+## nph-refresh -- script NPH/CGI pour l'actualisation automatique de
+## pages
+## Copyright (c) 1997 Ralf S. Engelschall, All Rights Reserved.
+##
+$| = 1;
+
+# éclate la variable QUERY_STRING
+@pairs = split(/&/, $ENV{'QUERY_STRING'});
+foreach $pair (@pairs) {
+ ($name, $value) = split(/=/, $pair);
+ $name =~ tr/A-Z/a-z/;
+ $name = 'QS_' . $name;
+ $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
+ eval "\$$name = \"$value\"";
+}
+$QS_s = 1 if ($QS_s eq '');
+$QS_n = 3600 if ($QS_n eq '');
+if ($QS_f eq '') {
+ print "HTTP/1.0 200 OK\n";
+ print "Content-type: text/html\n\n";
+ print "&lt;b&gt;ERREUR&lt;/b&gt;: Aucun fichier fourni\n";
+ exit(0);
+}
+if (! -f $QS_f) {
+ print "HTTP/1.0 200 OK\n";
+ print "Content-type: text/html\n\n";
+ print "&lt;b&gt;ERREUR&lt;/b&gt;: Fichier $QS_f non trouvé\n";
+ exit(0);
+}
+
+sub print_http_headers_multipart_begin {
+ print "HTTP/1.0 200 OK\n";
+ $bound = "ThisRandomString12345";
+ print "Content-type: multipart/x-mixed-replace;boundary=$bound\n";
+ &print_http_headers_multipart_next;
+}
+
+sub print_http_headers_multipart_next {
+ print "\n--$bound\n";
+}
+
+sub print_http_headers_multipart_end {
+ print "\n--$bound--\n";
+}
+
+sub displayhtml {
+ local($buffer) = @_;
+ $len = length($buffer);
+ print "Content-type: text/html\n";
+ print "Content-length: $len\n\n";
+ print $buffer;
+}
+
+sub readfile {
+ local($file) = @_;
+ local(*FP, $size, $buffer, $bytes);
+ ($x, $x, $x, $x, $x, $x, $x, $size) = stat($file);
+ $size = sprintf("%d", $size);
+ open(FP, "&lt;$file");
+ $bytes = sysread(FP, $buffer, $size);
+ close(FP);
+ return $buffer;
+}
+
+$buffer = &readfile($QS_f);
+&print_http_headers_multipart_begin;
+&displayhtml($buffer);
+
+sub mystat {
+ local($file) = $_[0];
+ local($time);
+
+ ($x, $x, $x, $x, $x, $x, $x, $x, $x, $mtime) = stat($file);
+ return $mtime;
+}
+
+$mtimeL = &mystat($QS_f);
+$mtime = $mtime;
+for ($n = 0; $n &lt; $QS_n; $n++) {
+ while (1) {
+ $mtime = &mystat($QS_f);
+ if ($mtime ne $mtimeL) {
+ $mtimeL = $mtime;
+ sleep(2);
+ $buffer = &readfile($QS_f);
+ &print_http_headers_multipart_next;
+ &displayhtml($buffer);
+ sleep(5);
+ $mtimeL = &mystat($QS_f);
+ last;
+ }
+ sleep($QS_s);
+ }
+}
+
+&print_http_headers_multipart_end;
+
+exit(0);
+
+##EOF##
+</pre></div>
+ </dd>
+ </dl>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="mass-virtual-hosting" id="mass-virtual-hosting">Hébergement virtuel de masse</a></h2>
+
+
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>La fonctionnalité <code class="directive"><a href="../mod/core.html#virtualhost"><VirtualHost></a></code> d'Apache est intéressante et
+ fonctionne de manière satisfaisante jusqu'à quelques
+ douzaines de serveurs virtuels. Par contre, si vous êtes un
+ FAI et devez héberger des centaines de serveurs virtuels,
+ cette méthode n'est pas optimale.</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>Pour fournir cette fonctionnalité avec
+ <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>, on fait correspondre à notre espace de
+ nommage la page web ou même le répertoire complet distants en
+ utilisant la fonctionnalité <dfn>Mandataire</dfn>
+ (drapeau <code>[P]</code>) :</p>
+
+<div class="example"><pre>
+##
+## vhost.map
+##
+www.vhost1.dom:80 /chemin/vers/racine-doc/vhost1
+www.vhost2.dom:80 /chemin/vers/racine-doc/vhost2
+ :
+www.vhostN.dom:80 /chemin/vers/racine-doc/vhostN
+</pre></div>
+
+<div class="example"><pre>
+##
+## httpd.conf
+##
+ :
+# utilisation du nom d'hôte canonique pour les redirections, etc...
+UseCanonicalName on
+
+ :
+# ajout du serveur virtuel en tête du format CLF
+CustomLog /chemin/vers/access_log "%{VHOST}e %h %l %u %t \"%r\" %>s %b"
+ :
+
+# activation du moteur de réécriture pour le serveur principal
+RewriteEngine on
+
+# définition de deux tables de correspondances : une première pour
+# corriger les URLs et une seconde qui associe les serveurs virtuels
+# disponibles avec leurs racines des documents correspondantes.
+RewriteMap lowercase int:tolower
+RewriteMap vhost txt:/chemin/vers/vhost.map
+
+# et enfin sélection proprement dite du serveur virtuel approprié via
+# une seule règle longue et complexe :
+#
+# 1. on s'assure de ne pas sélectionner un hôte virtuel pour les
+# adresses communes
+
+RewriteCond %{REQUEST_URI} !^/adresse-commune1/.*
+RewriteCond %{REQUEST_URI} !^/adresse-commune2/.*
+ :
+RewriteCond %{REQUEST_URI} !^/adresse-communeN/.*
+#
+# 2. on vérifie que l'on dispose bien d'un en-tête Host, car
+# actuellement, cette méthode ne peut faire de l'hébergement virtuel
+# qu'avec cet en-tête
+RewriteCond %{HTTP_HOST} !^$
+#
+# 3. mise en minuscules du nom d'hôte
+RewriteCond ${lowercase:%{HTTP_HOST}|NONE} ^(.+)$
+#
+# 4. recherche ce ce nom d'hôte dans vhost.map et
+# enregistrement de celui-ci seulement s'il s'agit d'un chemin
+# (et non "NONE" en provenance de la condition précédente)
+RewriteCond ${vhost:%1} ^(/.*)$
+#
+# 5. nous pouvons enfin faire correspondre l'URL avec la racine des
+# documents correspondant au serveur virtuel approprié et enregistrer
+# ce dernier à des fins de journalisation
+RewriteRule ^/(.*)$ %1/$1 [E=VHOST:${lowercase:%{HTTP_HOST}}]
+ :
+</pre></div>
+ </dd>
+ </dl>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="host-deny" id="host-deny">Interdiction d'hôtes</a></h2>
+
+
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Comment interdire l'accès à notre serveur à une liste
+ d'hôtes ?</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>Pour Apache >= 1.3b6 :</p>
+
+<div class="example"><pre>
+RewriteEngine on
+RewriteMap hôtes-interdits txt:/chemin/vers/hôtes-interdits
+RewriteCond ${hôtes-interdits:%{REMOTE_HOST}|NOT-FOUND} !=NOT-FOUND [OR]
+RewriteCond ${hôtes-interdits:%{REMOTE_ADDR}|NOT-FOUND} !=NOT-FOUND
+RewriteRule ^/.* - [F]
+</pre></div>
+
+ <p>Pour Apache <= 1.3b6 :</p>
+
+<div class="example"><pre>
+RewriteEngine on
+RewriteMap hôtes-interdits txt:/chemin/vers/hôtes-interdits
+RewriteRule ^/(.*)$ ${hôtes-interdits:%{REMOTE_HOST}|NOT-FOUND}/$1
+RewriteRule !^NOT-FOUND/.* - [F]
+RewriteRule ^NOT-FOUND/(.*)$ ${hôtes-interdits:%{REMOTE_ADDR}|NOT-FOUND}/$1
+RewriteRule !^NOT-FOUND/.* - [F]
+RewriteRule ^NOT-FOUND/(.*)$ /$1
+</pre></div>
+
+<div class="example"><pre>
+##
+## hosts.deny
+##
+## ATTENTION! Ceci est une table de correspondances, pas une liste,
+## même si on l'utilise en tant que telle. mod_rewrite l'interprète
+## comme un ensemble de paires clé/valeur ; chaque entrée doit donc
+## au moins posséder une valeur fictive "-".
+##
+
+193.102.180.41 -
+bsdti1.sdm.de -
+192.76.162.40 -
+</pre></div>
+ </dd>
+ </dl>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="proxy-deny" id="proxy-deny">Interdiction du mandataire</a></h2>
+
+
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Comment interdire l'utilisation du mandataire d'Apache pour
+ un certain hôte, ou même seulement pour un utilisateur
+ de cet hôte ?</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>Nous devons tout d'abord nous assurer que
+ <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code> arrive après(!)
+ <code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code> dans le fichier de configuration
+ lors de la compilation du serveur web Apache. De cette façon,
+ il est appelé <em>avant</em> <code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code>. Nous
+ pouvons ensuite définir cette règle pour une interdiction
+ dépendant de l'hôte :</p>
+
+<div class="example"><pre>
+RewriteCond %{REMOTE_HOST} <strong>^hôte-à-rejeter\.mon-domaine\.com$</strong>
+RewriteRule !^http://[^/.]\.mon-domaine.com.* - [F]
+</pre></div>
+
+ <p>...et celle-ci pour une interdiction dépendant de
+ utilisateur@hôte :</p>
+
+<div class="example"><pre>
+RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} <strong>^utilisateur-à-
+rejeter@hôte-à-rejeter\.mon-domaine\.com$</strong>
+RewriteRule !^http://[^/.]\.mon-domaine.com.* - [F]
+</pre></div>
+ </dd>
+ </dl>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="special-authentication" id="special-authentication">Variante particulière d'authentification</a></h2>
+
+
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>On a parfois besoin d'une authentification très
+ particulière, par exemple une authentification qui vérifie la
+ présence d'un utilisateur dans une liste explicitement
+ définie. Seuls ceux qui sont présents dans la liste se voient
+ accorder un accès, et ceci sans avoir à
+ s'identifier/authentifier (comme c'est le cas avec une
+ authentification de base via <code class="module"><a href="../mod/mod_auth.html">mod_auth</a></code>).</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>On définit une liste de conditions de réécriture pour
+ interdire l'accès à tout le monde, sauf aux utilisateurs
+ autorisés :</p>
+
+<div class="example"><pre>
+RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} <strong>!^ami1@client1.quux-corp\.com$</strong>
+RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} <strong>!^ami2</strong>@client2.quux-corp\.com$
+RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} <strong>!^ami3</strong>@client3.quux-corp\.com$
+RewriteRule ^/~quux/seulement-pour-les-amis/ - [F]
+</pre></div>
+ </dd>
+ </dl>
+
+ </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="referer-deflector" id="referer-deflector">Redirection basée sur le référent</a></h2>
+
+
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Comment écrire un programme souple qui redirige certaines
+ URLs en se basant sur l'en-tête HTTP "Referer", et peut être
+ configuré avec autant de pages de référence
+ que l'on veut ?</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>On utilise le jeu de règles vraiment astucieux suivant :</p>
+
+<div class="example"><pre>
+RewriteMap deflector txt:/chemin/vers/deflector.map
+
+RewriteCond %{HTTP_REFERER} !=""
+RewriteCond ${deflector:%{HTTP_REFERER}} ^-$
+RewriteRule ^.* %{HTTP_REFERER} [R,L]
+
+RewriteCond %{HTTP_REFERER} !=""
+RewriteCond ${deflector:%{HTTP_REFERER}|NOT-FOUND} !=NOT-FOUND
+RewriteRule ^.* ${deflector:%{HTTP_REFERER}} [R,L]
+</pre></div>
+
+ <p>... en association avec la table de réécriture
+ correspondante :</p>
+
+<div class="example"><pre>
+##
+## deflector.map
+##
+
+http://www.mauvais-sujets.com/mauvais/index.html -
+http://www.mauvais-sujets.com/mauvais/index2.html -
+http://www.mauvais-sujets.com/mauvais/index3.html http://quelque-part.com/
+</pre></div>
+
+ <p>Les requêtes sont redirigées vers la page de référence
+ (lorsque la valeur correspondant à la clé extraite de la table
+ de correspondances est égale à "<code>-</code>"), ou vers une
+ URL spécifique (lorsqu'une URL est définie dans la table de
+ correspondances comme second argument).</p>
+ </dd>
+ </dl>
+
+ </div></div>
+<div class="bottomlang">
+<p><span>Langues Disponibles: </span><a href="../en/rewrite/rewrite_guide_advanced.html" hreflang="en" rel="alternate" title="English"> en </a> |
+<a href="../fr/rewrite/rewrite_guide_advanced.html" title="Français"> fr </a></p>
+</div><div id="footer">
+<p class="apache">Copyright 2009 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>
\ No newline at end of file
--- /dev/null
+<?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 : 728400 -->
+<!-- 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="rewrite_guide_advanced.xml.meta">
+ <parentdocument href="./">Rewrite</parentdocument>
+
+ <title>Guide de réécriture des URLs - Sujets avancés</title>
+
+ <summary>
+
+ <p>Ce document complémente la
+ <a href="../mod/mod_rewrite.html">documentation de référence</a> du
+ module <module>mod_rewrite</module>. Il décrit les différentes
+ manières d'utiliser le module d'Apache <module>mod_rewrite</module>
+ pour résoudre les problèmes d'URLs typiques auxquels sont souvent
+ confrontés les webmasters. Nous fournissons une description
+ détaillée de la résolution de chaque problème par la configuration
+ d'un jeu de règles de réécriture.</p>
+
+ <note type="warning">ATTENTION: il pourra s'avérer nécessaire de
+ modifier les exemples en fonction de la
+ configuration de votre serveur, par exemple en ajoutant le drapeau
+ <code>[PT]</code> si les modules <module>mod_alias</module> et
+ <module>mod_userdir</module> sont utilisés, etc... Les jeux de
+ règles devront également être adaptés pour passer d'un contexte de
+ serveur à un contexte de répertoire (fichiers
+ <code>.htaccess</code>). Essayez de toujours bien comprendre ce que
+ fait un jeu de règles avant de l'utiliser, ce qui pourra vous éviter
+ bien des problèmes.</note>
+
+ </summary>
+<seealso><a href="../mod/mod_rewrite.html">Documentation du
+module</a></seealso>
+<seealso><a href="rewrite_intro.html">Introduction à
+mod_rewrite</a></seealso>
+<seealso><a href="rewrite_guide.html">Guide de réécriture - exemples
+utiles</a></seealso>
+<seealso><a href="rewrite_tech.html">Détails techniques</a></seealso>
+
+
+ <section id="cluster">
+
+ <title>Accès à une grappe de serveurs via un espace d'adressage
+ compatible</title>
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Comment créer un espace d'adressage homogène et compatible
+ avec
+ tous les serveurs WWW d'une grappe de serveurs d'un intranet ?
+ C'est à dire que toutes les URLs (par définition
+ locales à un
+ serveur et dépendant donc de celui-ci) deviennent
+ véritablement <em>indépendantes</em> du serveur ! Nous voulons
+ disposer, pour accéder à l'espace de nommage WWW, d'un seul
+ espace d'adressage compatible : aucune URL ne
+ doit inclure d'information quelconque à propos du serveur
+ cible physique. La grappe de serveurs doit elle-même nous
+ diriger automatiquement vers le bon serveur cible physique,
+ selon les besoins, et ceci de manière transparente.</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>Tout d'abord, la connaissance des serveurs cibles est issue
+ de tables de correspondances externes (distribuées) qui
+ contiennent des informations sur la localisation de nos
+ utilisateurs, groupes et entités. Elles se présentent sous la
+ forme :</p>
+
+<example><pre>
+utilisateur1 serveur_utilisateur1
+utilisateur2 serveur_utilisateur2
+: :
+</pre></example>
+
+ <p>On les enregistre sous forme de fichiers
+ <code>map.xxx-vers-serveur</code>. On doit ensuite faire
+ rediriger à tous les serveurs les URLs de la forme :</p>
+
+<example><pre>
+/u/utilisateur/chemin
+/g/groupe/chemin
+/e/entité/chemin
+</pre></example>
+
+ <p>vers</p>
+
+<example><pre>
+http://serveur-physique/u/utilisateur/chemin
+http://serveur-physique/g/groupe/chemin
+http://serveur-physique/e/entité/chemin
+</pre></example>
+
+ <p>si il n'est pas nécessaire que chaque chemin d'URL être valide sur chaque
+ serveur. Le jeu
+ de règles suivant le fait pour nous à l'aide des fichiers de
+ correspondance (en supposant que serveur0 soit un serveur par
+ défaut qui sera choisi si l'utilisateur ne possède aucune
+ entrée dans la table) :</p>
+
+<example><pre>
+RewriteEngine on
+
+RewriteMap utilisateur-vers-serveur txt:/chemin/vers/map.utilisateur-vers-serveur
+RewriteMap groupe-vers-serveur txt:/chemin/vers/map.groupe-vers-serveur
+RewriteMap entité-vers-serveur txt:/chemin/vers/map.entité-vers-serveur
+
+RewriteRule ^/u/<strong>([^/]+)</strong>/?(.*)
+http://<strong>${utilisateur-vers-serveur:$1|serveur0}</strong>/u/$1/$2
+RewriteRule ^/g/<strong>([^/]+)</strong>/?(.*)
+http://<strong>${groupe-vers-serveur:$1|serveur0}</strong>/g/$1/$2
+RewriteRule ^/e/<strong>([^/]+)</strong>/?(.*)
+http://<strong>${entité-vers-serveur:$1|serveur0}</strong>/e/$1/$2
+
+RewriteRule ^/([uge])/([^/]+)/?$ /$1/$2/.www/
+RewriteRule ^/([uge])/([^/]+)/([^.]+.+) /$1/$2/.www/$3\
+</pre></example>
+ </dd>
+ </dl>
+
+ </section>
+
+ <section id="structuredhomedirs">
+
+ <title>Répertoires utilisateurs structurés</title>
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Certains sites possédant des milliers d'utilisateurs
+ organisent les répertoires home de manière
+ structurée, <em>c'est à dire</em> que chaque répertoire home
+ se situe dans un sous-répertoire dont le nom commence (par
+ exemple) par le premier caractère du nom de l'utilisateur.
+ Ainsi, <code>/~foo/chemin</code> est dans
+ <code>/home/<strong>f</strong>/foo/.www/chemin</code>, tandis
+ que <code>/~bar/chemin</code> est dans
+ <code>/home/<strong>b</strong>/bar/.www/chemin</code>.</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>Le jeu de règles suivant permet de développer les URLs avec
+ tilde selon la représentation ci-dessus.</p>
+
+<example><pre>
+RewriteEngine on
+RewriteRule ^/~(<strong>([a-z])</strong>[a-z0-9]+)(.*) /home/<strong>$2</strong>/$1/.www$3
+</pre></example>
+ </dd>
+ </dl>
+
+ </section>
+
+ <section id="filereorg">
+
+ <title>Réorganisation du système de fichiers</title>
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Voici un cas d'espèce : une application très efficace qui
+ fait un usage intensif de règles <code>RewriteRule</code>
+ dans le contexte du répertoire pour présenter un aspect
+ compréhensible sur le Web sans modifier la structure des
+ données.
+ Les coulisses de l'affaire : <strong><em>net.sw</em></strong>
+ rassemble mes archives de paquetages de logiciels Unix
+ librement accessibles, que j'ai commencé à collectionner en
+ 1992. Pour moi, c'est un passe-temps, mais aussi un travail,
+ car alors que j'étudie la science informatique, j'ai aussi
+ travaillé depuis de nombreuses années comme administrateur
+ système et réseau à mes heures perdues. Chaque semaine j'ai
+ besoin de tel ou tel logiciel, et j'ai donc créé une
+ arborescence très ramifiée de répertoires où je stocke les
+ paquetages :</p>
+
+<example><pre>
+drwxrwxr-x 2 netsw users 512 Aug 3 18:39 Audio/
+drwxrwxr-x 2 netsw users 512 Jul 9 14:37 Benchmark/
+drwxrwxr-x 12 netsw users 512 Jul 9 00:34 Crypto/
+drwxrwxr-x 5 netsw users 512 Jul 9 00:41 Database/
+drwxrwxr-x 4 netsw users 512 Jul 30 19:25 Dicts/
+drwxrwxr-x 10 netsw users 512 Jul 9 01:54 Graphic/
+drwxrwxr-x 5 netsw users 512 Jul 9 01:58 Hackers/
+drwxrwxr-x 8 netsw users 512 Jul 9 03:19 InfoSys/
+drwxrwxr-x 3 netsw users 512 Jul 9 03:21 Math/
+drwxrwxr-x 3 netsw users 512 Jul 9 03:24 Misc/
+drwxrwxr-x 9 netsw users 512 Aug 1 16:33 Network/
+drwxrwxr-x 2 netsw users 512 Jul 9 05:53 Office/
+drwxrwxr-x 7 netsw users 512 Jul 9 09:24 SoftEng/
+drwxrwxr-x 7 netsw users 512 Jul 9 12:17 System/
+drwxrwxr-x 12 netsw users 512 Aug 3 20:15 Typesetting/
+drwxrwxr-x 10 netsw users 512 Jul 9 14:08 X11/
+</pre></example>
+
+ <p>J'ai décidé en 1996 de rendre cette archive disponible pour
+ le monde via une interface web agréable. "Agréable" signifie
+ que je voulais vous offrir une interface où vous pourriez
+ naviguer directement à travers la hiérarchie des archives.
+ Mais "agréable" signifie aussi que je ne voulais rien changer
+ dans cette hiérarchie - même pas en ajoutant queques scripts
+ CGI à son sommet. Pourquoi ? Parceque j'avais prévu de rendre
+ ultérieurement la structure ci-dessus accessible aussi via
+ FTP, et je ne voulais pas voir de fichiers CGI ou Web à ce
+ niveau.</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>La solution comporte deux parties : la première consiste en
+ un ensemble de scripts CGI qui créent toutes les pages à tous
+ les niveaux de répertoires à la volée. Je les ai placés dans
+ <code>/e/netsw/.www/</code> comme suit :</p>
+
+<example><pre>
+-rw-r--r-- 1 netsw users 1318 Aug 1 18:10 .wwwacl
+drwxr-xr-x 18 netsw users 512 Aug 5 15:51 DATA/
+-rw-rw-rw- 1 netsw users 372982 Aug 5 16:35 LOGFILE
+-rw-r--r-- 1 netsw users 659 Aug 4 09:27 TODO
+-rw-r--r-- 1 netsw users 5697 Aug 1 18:01 netsw-about.html
+-rwxr-xr-x 1 netsw users 579 Aug 2 10:33 netsw-access.pl
+-rwxr-xr-x 1 netsw users 1532 Aug 1 17:35 netsw-changes.cgi
+-rwxr-xr-x 1 netsw users 2866 Aug 5 14:49 netsw-home.cgi
+drwxr-xr-x 2 netsw users 512 Jul 8 23:47 netsw-img/
+-rwxr-xr-x 1 netsw users 24050 Aug 5 15:49 netsw-lsdir.cgi
+-rwxr-xr-x 1 netsw users 1589 Aug 3 18:43 netsw-search.cgi
+-rwxr-xr-x 1 netsw users 1885 Aug 1 17:41 netsw-tree.cgi
+-rw-r--r-- 1 netsw users 234 Jul 30 16:35 netsw-unlimit.lst
+</pre></example>
+
+ <p>Le sous-répertoire <code>DATA/</code> contient la structure
+ de répertoires proprement dite mentionnée plus haut, <em>c'est
+ à dire</em> les véritables ressources
+ <strong><em>net.sw</em></strong> et est mis à jour
+ automatiquement via <code>rdist</code> à intervalles de temps
+ réguliers. Reste la seconde partie du problème : comment
+ relier ces deux structures selon une arborescence d'URL
+ facile d'accès ? Il nous faut cacher le répertoire
+ <code>DATA/</code> à l'utilisateur durant l'exécution des
+ scripts CGI appropriés aux différentes URLs. Voici comment :
+ tout d'abord, j'ajoute ces deux règles dans le fichier de
+ configuration du répertoire racine <directive
+ module="core">DocumentRoot</directive> du serveur afin de
+ réécrire le chemin d'URL public <code>/net.sw/</code> vers le
+ chemin interne <code>/e/netsw</code> :</p>
+
+<example><pre>
+RewriteRule ^net.sw$ net.sw/ [R]
+RewriteRule ^net.sw/(.*)$ e/netsw/$1
+</pre></example>
+
+ <p>La première règle concerne les requêtes qui ne comportent
+ pas de slash de fin ! C'est la seconde règle qui fait le
+ véritable travail. Et maintenant vient la super configuration
+ qui se trouve dans le fichier de configuration de répertoire
+ <code>/e/netsw/.www/.wwwacl</code> :</p>
+
+<example><pre>
+Options ExecCGI FollowSymLinks Includes MultiViews
+
+RewriteEngine on
+
+# l'accès s'effectue via le préfixe /net.sw/
+RewriteBase /net.sw/
+
+# tout d'abord, on réécrit le répertoire racine vers
+# le script CGI qui lui est associé
+RewriteRule ^$ netsw-home.cgi [L]
+RewriteRule ^index\.html$ netsw-home.cgi [L]
+
+# on supprime les sous-répertoires lorsque
+# le navigateur nous atteint depuis des pages de répertoire
+RewriteRule ^.+/(netsw-[^/]+/.+)$ $1 [L]
+
+# on stoppe maintenant la réécriture pour les fichiers locaux
+RewriteRule ^netsw-home\.cgi.* - [L]
+RewriteRule ^netsw-changes\.cgi.* - [L]
+RewriteRule ^netsw-search\.cgi.* - [L]
+RewriteRule ^netsw-tree\.cgi$ - [L]
+RewriteRule ^netsw-about\.html$ - [L]
+RewriteRule ^netsw-img/.*$ - [L]
+
+# ce qui reste est un sous-répertoire qui peut être traité
+# par un autre script CGI
+RewriteRule !^netsw-lsdir\.cgi.* - [C]
+RewriteRule (.*) netsw-lsdir.cgi/$1
+</pre></example>
+
+ <p>Quelques indices pour l'interprétation :</p>
+
+ <ol>
+ <li>Remarquez le drapeau <code>L</code> (last) et l'absence
+ de chaîne de substitution ('<code>-</code>') dans la
+ quatrième partie.</li>
+
+ <li>Remarquez le caractère <code>!</code> (not) et le
+ drapeau <code>C</code> (chain) dans la première règle de la
+ dernière partie.</li>
+
+ <li>Remarquez le modèle qui correspond à tout dans la
+ dernière règle.</li>
+ </ol>
+ </dd>
+ </dl>
+
+ </section>
+
+ <section id="redirect404">
+
+ <title>Rediriger les URLs erronées vers un autre serveur Web</title>
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Une question typique de la FAQ à propos de la réécriture
+ revient souvent : comment rediriger vers un serveur B les
+ requêtes qui échouent sur un serveur A ? On s'acquitte en
+ général de cette tâche via des scripts CGI <directive
+ module="core">ErrorDocument</directive> en Perl, mais il
+ existe aussi une solution avec <module>mod_rewrite</module>.
+ Notez cependant que les performances sont moindres qu'avec
+ l'utilisation d'un script CGI <directive
+ module="core">ErrorDocument</directive> !</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>La première solution possède des performances supérieures
+ mais moins de souplesse, et est moins sure :</p>
+
+<example><pre>
+RewriteEngine on
+RewriteCond %{DOCUMENT_ROOT/%{REQUEST_URI} <strong>!-f</strong>
+RewriteRule ^(.+) http://<strong>serveurB</strong>.dom/$1
+</pre></example>
+
+ <p>Le problème réside dans le fait que seules les pages
+ situées dans la racine <directive
+ module="core">DocumentRoot</directive> seront redirigées. Mais
+ même si vous pouvez ajouter des conditions supplémentaires (par
+ exemple pour traiter aussi les répertoires home, etc...), il
+ existe une meilleure solution :</p>
+
+<example><pre>
+RewriteEngine on
+RewriteCond %{REQUEST_URI} <strong>!-U</strong>
+RewriteRule ^(.+) http://<strong>serveurB</strong>.dom/$1
+</pre></example>
+reprendre ici
+ <p>On utilise ici la fonctionnalité de prévision des URLs
+ futures de <module>mod_rewrite</module>. Et cette solution
+ fonctionne pour tous les types d'URLs et de manière sûre. Par
+ contre, cette méthode a un impact sur les performances du
+ serveur web, car chaque requête entraîne le traitement d'une
+ sous-requête interne supplémentaire. Par conséquent, vous
+ pouvez l'utiliser si votre serveur web s'exécute sur un CPU
+ puissant. Dans le cas d'une machine plus lente, utilisez la
+ première approche, ou mieux, un script CGI <directive
+ module="core">ErrorDocument</directive>.</p>
+ </dd>
+ </dl>
+
+ </section>
+
+ <section id="archive-access-multiplexer">
+
+ <title>Multiplexeur d'accès aux archives</title>
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Connaissez-vous la grande archive CPAN (Comprehensive Perl Archive
+ Network) située à <a href="http://www.perl.com/CPAN"
+ >http://www.perl.com/CPAN</a> ?
+ CPAN redirige automatiquement les navigateurs vers un des
+ nombreux serveurs FTP répartis à travers le monde
+ (généralement un serveur assez proche du client) ; chaque
+ serveur héberge l'intégralité d'un miroir CPAN. Il s'agit ni
+ plus ni moins qu'un service d'accès FTP multiplexé. Alors que
+ le fonctionnement de l'archive CPAN repose sur des scripts
+ CGI, comment implémenter une approche similaire avec
+ <module>mod_rewrite</module> ?</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>Premièrement, remarquons que depuis la version 3.0.0,
+ <module>mod_rewrite</module> accepte aussi le préfixe
+ "<code>ftp:</code>" dans les redirections. Et deuxièmement,
+ l'approximation de la localisation peut être effectuée par une
+ table de correspondances <directive
+ module="mod_rewrite">RewriteMap</directive>, en se basant sur
+ la racine du domaine du client. Un jeu de règles chaînées
+ astucieux nous permet d'utiliser cette racine du domaine comme
+ clé de recherche dans notre table de correspondances de
+ multiplexage.</p>
+
+<example><pre>
+RewriteEngine on
+RewriteMap multiplex txt:/chemin/vers/map.cxan
+RewriteRule ^/CxAN/(.*) %{REMOTE_HOST}::$1 [C]
+RewriteRule ^.+\.<strong>([a-zA-Z]+)</strong>::(.*)$
+${multiplex:<strong>$1</strong>|ftp.défaut.dom}$2 [R,L]
+</pre></example>
+
+<example><pre>
+##
+## map.cxan -- Multiplexing Map for CxAN%{DOCUMENT_ROOT/%{REQUEST_URI}
+##
+
+de ftp://ftp.cxan.de/CxAN/
+uk ftp://ftp.cxan.uk/CxAN/
+com ftp://ftp.cxan.com/CxAN/
+ :
+##EOF##
+</pre></example>
+ </dd>
+ </dl>
+
+ </section>
+
+ <section id="browser-dependent-content">
+
+ <title>Contenu dépendant du navigateur</title>
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Il est parfois nécessaire, au moins pour les pages
+ principales, de fournir un contenu optimum adapté à chaque
+ type de navigateur, c'est à dire que l'on doit
+ fournir une version pour les navigateurs courants, une version
+ différente pour les navigateurs en mode texte du style de
+ Lynx, et une autre pour les autres navigateurs.</p>
+ </dd>
+
+ <dt>Solution :</dt>%{DOCUMENT_ROOT/%{REQUEST_URI}
+
+ <dd>
+ <p>On ne peut pas utiliser la négociation de contenu car les
+ navigateurs ne fournissent pas leur type dans cette forme.
+ Nous devons nous baser sur l'en-tête HTTP "User-Agent". La
+ configuration ci-dessous effectue les actions suivantes : si
+ l'en-tête HTTP "User-Agent" commence par "Mozilla/3", la page
+ <code>foo.html</code> est réécrite en <code>foo.NS.html</code>
+ et la réécriture s'arrête. Si le navigateur est "Lynx" ou
+ "Mozilla" version 1 ou 2, la page
+ <code>foo.html</code> est réécrite en
+ <code>foo.20.html</code>. Tous les autres navigateurs
+ reçoivent la page <code>foo.32.html</code>. Voici le jeu de
+ règles :</p>
+
+<example><pre>
+RewriteCond %{HTTP_USER_AGENT} ^<strong>Mozilla/3</strong>.*
+RewriteRule ^foo\.html$ foo.<strong>NS</strong>.html [<strong>L</strong>]
+
+RewriteCond %{HTTP_USER_AGENT} ^<strong>Lynx/</strong>.* [OR]
+RewriteCond %{HTTP_USER_AGENT} ^<strong>Mozilla/[12]</strong>.*
+RewriteRule ^foo\.html$ foo.<strong>20</strong>.html [<strong>L</strong>]
+
+RewriteRule ^foo\.html$ foo.<strong>32</strong>.html [<strong>L</strong>]
+</pre></example>
+ </dd>
+ </dl>
+
+ </section>
+
+ <section id="dynamic-mirror">
+
+ <title>Miroir dynamique</title>
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Supposons que nous voulions intégrer dans notre espace de
+ nommage de belles pages web situées sur un serveur distant.
+ Dans le cas d'un serveur FTP, nous aurions utilisé le
+ programme <code>mirror</code> qui maintient vraiment une copie
+ des données distantes mise à jour explicitement sur le serveur
+ local. Pour un serveur web, nous pourrions utiliser le
+ programme <code>webcopy</code> qui utilise le protocole HTTP.
+ Ces deux techniques présentent cependant un
+ inconvénient majeur : la copie locale n'est véritablement à
+ jour qu'au moment où nous avons lancé le programme. Plutôt qu'
+ un miroir statique devant être défini explicitement, il serait
+ préférable d'avoir un miroir dynamique dont le contenu serait
+ mis à jour automatiquement, à la demande, sur le(s) serveur(s)
+ distant(s).</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>Pour y parvenir, on fait
+ correspondre la page web ou même l'ensemble du
+ répertoire web distants à notre espace de nommage en utilisant
+ la fonctionnalité <dfn>Mandataire</dfn> (drapeau
+ <code>[P]</code> ou <code>[proxy]</code>) :</p>
+
+<example><pre>
+RewriteEngine on
+RewriteBase /~quux/
+RewriteRule ^<strong>page-convoitée/</strong>(.*)$ <strong>http://www.tstimpreso.com/page-convoitée/</strong>$1 [<strong>P</strong>]
+</pre></example>
+
+<example><pre>
+RewriteEngine on
+RewriteBase /~quux/
+RewriteRule ^<strong>usa-news\.html</strong>$ <strong>http://www.quux-corp.com/news/index.html</strong> [<strong>P</strong>]
+</pre></example>
+ </dd>
+ </dl>
+
+ </section>
+
+ <section id="reverse-dynamic-mirror">
+
+ <title>Miroir dynamique inverse</title>
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>...</dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+<example><pre>
+RewriteEngine on
+RewriteCond /miroir/du/site-distant/$1 -U
+RewriteRule ^http://www\.site-distant\.com/(.*)$ /miroir/du/site-distant/$1
+</pre></example>
+ </dd>
+ </dl>
+
+ </section>
+
+ <section id="retrieve-missing-data">
+
+ <title>Récupérer des données manquantes depuis l'Intranet</title>
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>C'est une méthode astucieuse permettant de faire
+ fonctionner virtuellement un serveur web d'entreprise
+ (<code>www.quux-corp.dom</code>) sur
+ l'Internet (extérieur à l'entreprise), tout en maintenant et
+ conservant dans la réalité ses données sur un serveur web
+ (<code>www2.quux-corp.dom</code>) de l'Intranet (interne à
+ l'entreprise) protégé par un pare-feu. L'astuce consiste, sur
+ le serveur web externe, à récupérer à la volée sur le serveur interne
+ les données demandées.</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>Tout d'abord, nous devons nous assurer que notre pare-feu
+ protège bien le serveur web interne, et que seul le serveur
+ web externe est autorisé à y récupérer des données. Dans le
+ cas d'un filtrage par paquets, nous pourrions par exemple
+ définir un jeu de règles du pare-feu du style :</p>
+
+<example><pre>
+<strong>ALLOW</strong> serveur www.quux-corp.dom Port >1024 -->
+serveur www2.quux-corp.dom Port <strong>80</strong>
+<strong>DENY</strong> serveur * Port * -->
+serveur www2.quux-corp.dom Port <strong>80</strong>
+</pre></example>
+
+ <p>Il vous suffit d'adapter ces règles à la syntaxe de votre
+ pare-feu. Nous pouvons maintenant définir les règles de
+ <module>mod_rewrite</module> qui serviront à récupérer les
+ données manquantes en arrière-plan via la fonctionnalité de
+ mandataire :</p>
+
+<example><pre>
+RewriteRule ^/~([^/]+)/?(.*) /home/$1/.www/$2 [C]
+# L'utilisation de REQUEST_FILENAME ci dessous est correcte dans cet
+# exemple de contexte au niveau serveur car la règle qui fait référence
+# à REQUEST_FILENAME est chaînée à une règle qui définit
+# REQUEST_FILENAME.
+RewriteCond %{REQUEST_FILENAME} <strong>!-f</strong>
+RewriteCond %{REQUEST_FILENAME} <strong>!-d</strong>
+RewriteRule ^/home/([^/]+)/.www/?(.*) http://<strong>www2</strong>.quux-corp.dom/~$1/pub/$2 [<strong>P</strong>]
+</pre></example>
+ </dd>
+ </dl>
+
+ </section>
+
+ <section id="load-balancing">
+
+ <title>Répartition de charge</title>
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Supposons que nous voulions répartir la charge du trafic
+ vers <code>www.example.com</code> entre les serveurs
+ <code>www[0-5].example.com</code> (un total de 6 serveurs).
+ Comment y parvenir ?</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>Il existe de nombreuses solutions à ce problème. Nous
+ décrirons tout d'abord une variante assez connue basée sur
+ DNS, puis une autre basée sur <module>mod_rewrite</module>
+ :</p>
+
+ <ol>
+ <li>
+ <strong>Round-Robin (tourniquet) DNS</strong>
+
+ <p>La méthode de répartition de charge la plus simple
+ consiste à utiliser le "DNS round-robin"
+ (rotation d'adresses) de
+ <code>BIND</code>. Vous devez seulement enregistrer les
+ serveurs <code>www[0-9].example.com</code> de manière
+ habituelle dans votre DNS à l'aide d'enregistrements de
+ type A (adresse), comme suit :</p>
+
+<example><pre>
+www0 IN A 1.2.3.1
+www1 IN A 1.2.3.2
+www2 IN A 1.2.3.3
+www3 IN A 1.2.3.4
+www4 IN A 1.2.3.5
+www5 IN A 1.2.3.6
+</pre></example>
+
+ <p>Puis vous ajoutez les entrées suivantes :</p>
+
+<example><pre>
+www IN A 1.2.3.1
+www IN A 1.2.3.2
+www IN A 1.2.3.3
+www IN A 1.2.3.4
+www IN A 1.2.3.5
+</pre></example>
+
+ <p>Maintenant, lors de la résolution de
+ <code>www.example.com</code>, <code>BIND</code> renvoie
+ <code>www0-www5</code> - mais selon une permutation
+ différente à chaque fois. De cette façon, les clients sont
+ répartis entre les différents serveurs. Notez cependant
+ que cette méthode de répartition de charge n'est pas
+ parfaite, car les résolutions DNS sont mises en cache par
+ les clients et les autres serveurs DNS du réseau, si
+ bien que lorsqu'un client s'est vu résoudre
+ <code>www.example.com</code> en un des
+ <code>wwwN.example.com</code>, toutes ses requêtes ultérieures
+ continueront d'aller vers la même adresse IP (et donc le
+ même serveur), au lieu d'être réparties entre les autres
+ serveurs. Le résultat est cependant globalement
+ satisfaisant car les requêtes sont réparties
+ collectivement entre chacun des serveurs web.</p>
+ </li>
+
+ <li>
+ <strong>Répartition de charge basée sur DNS</strong>
+
+ <p>Une méthode de répartition de charge sophistiquée basée
+ sur DNS consiste à utiliser le programme
+ <code>lbnamed</code> que l'on peut trouver à <a
+ href="http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html">
+ http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html</a>.
+ Associé à des outils auxiliaires, il s'agit d'un programme
+ en Perl 5 qui permet d'effectuer une véritable répartition
+ de charge basée sur DNS.</p>
+ </li>
+
+ <li>
+ <strong>Round-Robin basé sur la fonctionnalité de
+ mandataire</strong>
+
+ <p>Dans cette variante, nous utilisons
+ <module>mod_rewrite</module> et sa fonctionnalité de
+ mandataire. Tout d'abord, nous définissons
+ <code>www0.example.com</code> comme un autre nom de
+ <code>www.example.com</code> en ajoutant l'entrée</p>
+
+<example><pre>
+www IN CNAME www0.example.com.
+</pre></example>
+
+ <p>dans le DNS. Puis nous définissons
+ <code>www0.example.com</code> comme serveur mandataire
+ seulement, c'est à dire que nous configurons cette machine
+ de telle sorte que toutes les URLs qui lui arrivent soient
+ simplement transmises, via le mandataire interne, vers un
+ des 5 autres serveurs (<code>www1-www5</code>). Pour y
+ parvenir, nous définissons tout d'abord un jeu de règles
+ qui contacte un script de répartition de charge
+ <code>lb.pl</code> pour toutes les URLs.</p>
+
+<example><pre>
+RewriteEngine on
+RewriteMap lb prg:/chemin/vers/lb.pl
+RewriteRule ^/(.+)$ ${lb:$1} [P,L]
+</pre></example>
+
+ <p>Puis nous écrivons <code>lb.pl</code> :</p>
+
+<example><pre>
+#!/chemin/vers/perl
+##
+## lb.pl -- script de répartition de charge
+##
+
+$| = 1;
+
+$name = "www"; # la base du nom du serveur
+$first = 1; # le premier serveur (pas 0 ici, car 0 correspond à
+ # moi-même)
+$last = 5; # le dernier serveur du tourniquet
+$domain = "foo.dom"; # le nom de domaine
+
+$cnt = 0;
+while (<STDIN>) {
+ $cnt = (($cnt+1) % ($last+1-$first));
+ $server = sprintf("%s%d.%s", $name, $cnt+$first, $domain);
+ print "http://$server/$_";
+}
+
+##EOF##
+</pre></example>
+
+ <note>Une dernière remarque : à quoi cela sert-il ?
+ <code>www0.example.com</code>, quant à lui, n'est-il pas
+ toujours surchargé ? La réponse est oui, il est surchargé,
+ mais seulement avec des requêtes de mandataire ! Tous les
+ traitements SSI, CGI, ePerl, etc... sont entièrement
+ effectués sur les autres machines. Ceci peut fonctionner
+ correctement pour un site complexe. Le plus grand risque
+ réside ici dans le fait que www0 est un passage obligé et
+ que s'il est hors service, les autres serveurs deviennent
+ inaccessibles.</note>
+ </li>
+
+ <li>
+ <strong>Répartiteur de charge dédié</strong>
+
+ <p>Il existe aussi des solutions plus sophistiquées.
+ Cisco, F5, et de nombreuses autres sociétés proposent
+ des répartiteurs de charge matériels (utilisés en général
+ en mode doublé à des fins de redondance), qui offrent une
+ répartition de charge sophistiquée et des fonctionnalités
+ de passage automatique en mode de fonctionnement par défaut
+ en cas de problème. Cependant, des solutions logicielles
+ offrent aussi des fonctionnalités similaires avec du
+ matériel standard. Si vos besoins correspondent et si vous
+ êtes assez riche, vous pouvez envisager ces solutions. La
+ <a href="http://vegan.net/lb/">liste de diffusion lb-l</a>
+ est un bon point de départ pour vos recherches.</p>
+ </li>
+ </ol>
+ </dd>
+ </dl>
+
+ </section>
+
+ <section id="new-mime-type">
+
+ <title>Nouveau type MIME, nouveau service</title>
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>On trouve de nombreux programmes CGI attractifs sur le
+ réseau. Mais leur emploi est souvent rébarbatif, si bien que
+ de nombreux webmasters ne les utilisent pas. Même la
+ fonctionnalité de gestionnaire Action d'Apache pour les types
+ MIME ne convient que lorsque les programmes CGI ne nécessitent
+ pas d'URLs spéciales (réellement <code>PATH_INFO</code> et
+ <code>QUERY_STRINGS</code>) en entrée. Tout d'abord,
+ définissons un nouveau type de fichier ayant pour extension
+ <code>.scgi</code> (pour CGI sécurisé) qui sera associé pour
+ traitement au programme populaire <code>cgiwrap</code>. Le
+ problème est le suivant : par exemple, si on utilise un style
+ d'URL bien défini (voir ci-dessus), un fichier situé dans le
+ répertoire home de l'utilisateur pourra correspondre à l'URL
+ <code>/u/user/foo/bar.scgi</code>. Mais <code>cgiwrap</code>
+ nécessite des URLs de la forme
+ <code>/~user/foo/bar.scgi/</code>. La règle suivante apporte
+ la solution :</p>
+
+<example><pre>
+RewriteRule ^/[uge]/<strong>([^/]+)</strong>/\.www/(.+)\.scgi(.*) ...
+... /interne/cgi/utilisateur/cgiwrap/~<strong>$1</strong>/$2.scgi$3 [NS,<strong>T=application/x-http-cgi</strong>]
+</pre></example>
+
+ <p>Ou considérons ces autres programmes attractifs :
+ <code>wwwlog</code> (qui affiche le journal des accès
+ <code>access.log</code> pour un sous répertoire correspondant
+ à une URL) et <code>wwwidx</code> (qui exécute Glimpse sur un
+ sous répertoire correspondant à une URL). Nous devons fournir
+ l'URL correspondante à ces programmes afin qu'ils sachent sur
+ quel répertoire ils doivent agir. Mais c'est en général
+ compliqué, car ils peuvent être appelés à nouveau
+ par la forme d'URL alternative, c'est à dire que typiquement,
+ nous exécuterions le programme <code>swwidx</code> depuis
+ <code>/u/user/foo/</code> via un hyperlien vers</p>
+
+<example><pre>
+/internal/cgi/user/swwidx?i=/u/user/foo/
+</pre></example>
+
+ <p>ce qui n'est pas satisfaisant, car nous devons expliciter
+ <strong>à la fois</strong> la localisation du répertoire
+ <strong>et</strong> la localisation du programme CGI dans
+ l'hyperlien. Si nous devons nous réorganiser, il nous faudra
+ beaucoup de temps pour modifier tous les hyperliens.</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>La solution consiste ici à fournir un nouveau format d'URL
+ qui redirige automatiquement vers la requête CGI appropriée.
+ Pour cela, on définit les règles suivantes :</p>
+
+<example><pre>
+RewriteRule ^/([uge])/([^/]+)(/?.*)/\* /interne/cgi/utilisateur/wwwidx?i=/$1/$2$3/
+RewriteRule ^/([uge])/([^/]+)(/?.*):log /interne/cgi/utilisateur/wwwlog?f=/$1/$2$3
+</pre></example>
+
+ <p>Et maintenant l'hyperlien qui renvoie vers
+ <code>/u/user/foo/</code> se réduit à</p>
+
+<example><pre>
+HREF="*"
+</pre></example>
+
+ <p>qui est automatiquement transformé en interne en</p>
+
+<example><pre>
+/internal/cgi/user/wwwidx?i=/u/user/foo/
+</pre></example>
+
+ <p>Une approche similaire permet d'invoquer le programme CGI
+ du journal des accès lorsque l'hyperlien <code>:log</code> est
+ utilisé.</p>
+ </dd>
+ </dl>
+
+ </section>
+
+ <section id="on-the-fly-content">
+
+ <title>Régéneration de contenu à la volée</title>
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Voici une fonctionnalité vraiment ésotérique : des pages
+ générées dynamiquement mais servies statiquement, c'est à
+ dire que les pages doivent être servies comme des pages
+ purement statiques (lues depuis le système de fichiers et
+ servies en l'état), mais doivent être générées dynamiquement
+ par le serveur web si elles sont absentes. Ainsi, vous pouvez
+ avoir des pages générées par CGI qui sont servies statiquement
+ à moins qu'un administrateur (ou une tâche de
+ <code>cron</code>) ne supprime les
+ contenus statiques. Les contenus sont ensuite actualisés.</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ A cet effet, on utilise le jeu de règles suivant :
+
+<example><pre>
+# Cet exemple n'est valable que dans un contexte de répertoire
+RewriteCond %{REQUEST_FILENAME} <strong>!-s</strong>
+RewriteRule ^page\.<strong>html</strong>$ page.<strong>cgi</strong> [T=application/x-httpd-cgi,L]
+</pre></example>
+
+ <p>Ainsi, une requête pour <code>page.html</code> entraîne
+ l'exécution interne de la page <code>page.cgi</code>
+ correspondante si <code>page.html</code> n'existe pas
+ ou possède une taille de fichier nulle. L'astuce réside ici
+ dans le fait que <code>page.cgi</code> est un script CGI
+ qui (en plus de <code>STDOUT</code>) écrit sa sortie dans le
+ fichier <code>page.html</code>. Une fois le script exécuté, le
+ serveur sert la page <code>page.html</code> fraîchement
+ générée. Si le webmaster
+ veut actualiser les contenus, il lui suffit de supprimer le
+ fichier <code>page.html</code> (le plus souvent via une tâche
+ de <code>cron</code>).</p>
+ </dd>
+ </dl>
+
+ </section>
+
+ <section id="autorefresh">
+
+ <title>Actualisation automatique d'un document</title>
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Lorsque nous créons une page web complexe, ne serait-il pas
+ souhaitable que le navigateur web actualise automatiquement la
+ page chaque fois que nous en sauvegardons une nouvelle version
+ à partir de notre éditeur ? Impossible ?</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>Non ! Nous allons pour cela combiner la fonctionnalité MIME
+ multipart, la fonctionnalité NPH du serveur web et la
+ puissance de <module>mod_rewrite</module> pour la manipulation
+ d'URLs. Tout d'abord, nous définissons une nouvelle
+ fonctionnalité pour les URLs : l'ajout de
+ <code>:refresh</code> à toute URL fait que la 'page' est
+ actualisée chaque fois que la ressource est mise à jour dans
+ le système de fichiers.</p>
+
+<example><pre>
+RewriteRule ^(/[uge]/[^/]+/?.*):refresh /interne/cgi/apache/nph-refresh?f=$1
+</pre></example>
+
+ <p>Nous appelons maintenant cette URL</p>
+
+<example><pre>
+/u/foo/bar/page.html:refresh
+</pre></example>
+
+ <p>ce qui entraîne en interne l'invocation de l'URL</p>
+
+<example><pre>
+/interne/cgi/apache/nph-refresh?f=/u/foo/bar/page.html
+</pre></example>
+
+ <p>Il ne reste plus qu'à écrire le script CGI. Bien que l'on
+ écrive habituellement dans ces cas "laissé à la charge du
+ lecteur à titre d'exercice", ;-) je vous l'offre, aussi.</p>
+
+<example><pre>
+#!/sw/bin/perl
+##
+## nph-refresh -- script NPH/CGI pour l'actualisation automatique de
+## pages
+## Copyright (c) 1997 Ralf S. Engelschall, All Rights Reserved.
+##
+$| = 1;
+
+# éclate la variable QUERY_STRING
+@pairs = split(/&/, $ENV{'QUERY_STRING'});
+foreach $pair (@pairs) {
+ ($name, $value) = split(/=/, $pair);
+ $name =~ tr/A-Z/a-z/;
+ $name = 'QS_' . $name;
+ $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
+ eval "\$$name = \"$value\"";
+}
+$QS_s = 1 if ($QS_s eq '');
+$QS_n = 3600 if ($QS_n eq '');
+if ($QS_f eq '') {
+ print "HTTP/1.0 200 OK\n";
+ print "Content-type: text/html\n\n";
+ print "&lt;b&gt;ERREUR&lt;/b&gt;: Aucun fichier fourni\n";
+ exit(0);
+}
+if (! -f $QS_f) {
+ print "HTTP/1.0 200 OK\n";
+ print "Content-type: text/html\n\n";
+ print "&lt;b&gt;ERREUR&lt;/b&gt;: Fichier $QS_f non trouvé\n";
+ exit(0);
+}
+
+sub print_http_headers_multipart_begin {
+ print "HTTP/1.0 200 OK\n";
+ $bound = "ThisRandomString12345";
+ print "Content-type: multipart/x-mixed-replace;boundary=$bound\n";
+ &print_http_headers_multipart_next;
+}
+
+sub print_http_headers_multipart_next {
+ print "\n--$bound\n";
+}
+
+sub print_http_headers_multipart_end {
+ print "\n--$bound--\n";
+}
+
+sub displayhtml {
+ local($buffer) = @_;
+ $len = length($buffer);
+ print "Content-type: text/html\n";
+ print "Content-length: $len\n\n";
+ print $buffer;
+}
+
+sub readfile {
+ local($file) = @_;
+ local(*FP, $size, $buffer, $bytes);
+ ($x, $x, $x, $x, $x, $x, $x, $size) = stat($file);
+ $size = sprintf("%d", $size);
+ open(FP, "&lt;$file");
+ $bytes = sysread(FP, $buffer, $size);
+ close(FP);
+ return $buffer;
+}
+
+$buffer = &readfile($QS_f);
+&print_http_headers_multipart_begin;
+&displayhtml($buffer);
+
+sub mystat {
+ local($file) = $_[0];
+ local($time);
+
+ ($x, $x, $x, $x, $x, $x, $x, $x, $x, $mtime) = stat($file);
+ return $mtime;
+}
+
+$mtimeL = &mystat($QS_f);
+$mtime = $mtime;
+for ($n = 0; $n &lt; $QS_n; $n++) {
+ while (1) {
+ $mtime = &mystat($QS_f);
+ if ($mtime ne $mtimeL) {
+ $mtimeL = $mtime;
+ sleep(2);
+ $buffer = &readfile($QS_f);
+ &print_http_headers_multipart_next;
+ &displayhtml($buffer);
+ sleep(5);
+ $mtimeL = &mystat($QS_f);
+ last;
+ }
+ sleep($QS_s);
+ }
+}
+
+&print_http_headers_multipart_end;
+
+exit(0);
+
+##EOF##
+</pre></example>
+ </dd>
+ </dl>
+
+ </section>
+
+ <section id="mass-virtual-hosting">
+
+ <title>Hébergement virtuel de masse</title>
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>La fonctionnalité <directive type="section" module="core"
+ >VirtualHost</directive> d'Apache est intéressante et
+ fonctionne de manière satisfaisante jusqu'à quelques
+ douzaines de serveurs virtuels. Par contre, si vous êtes un
+ FAI et devez héberger des centaines de serveurs virtuels,
+ cette méthode n'est pas optimale.</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>Pour fournir cette fonctionnalité avec
+ <module>mod_rewrite</module>, on fait correspondre à notre espace de
+ nommage la page web ou même le répertoire complet distants en
+ utilisant la fonctionnalité <dfn>Mandataire</dfn>
+ (drapeau <code>[P]</code>) :</p>
+
+<example><pre>
+##
+## vhost.map
+##
+www.vhost1.dom:80 /chemin/vers/racine-doc/vhost1
+www.vhost2.dom:80 /chemin/vers/racine-doc/vhost2
+ :
+www.vhostN.dom:80 /chemin/vers/racine-doc/vhostN
+</pre></example>
+
+<example><pre>
+##
+## httpd.conf
+##
+ :
+# utilisation du nom d'hôte canonique pour les redirections, etc...
+UseCanonicalName on
+
+ :
+# ajout du serveur virtuel en tête du format CLF
+CustomLog /chemin/vers/access_log "%{VHOST}e %h %l %u %t \"%r\" %>s %b"
+ :
+
+# activation du moteur de réécriture pour le serveur principal
+RewriteEngine on
+
+# définition de deux tables de correspondances : une première pour
+# corriger les URLs et une seconde qui associe les serveurs virtuels
+# disponibles avec leurs racines des documents correspondantes.
+RewriteMap lowercase int:tolower
+RewriteMap vhost txt:/chemin/vers/vhost.map
+
+# et enfin sélection proprement dite du serveur virtuel approprié via
+# une seule règle longue et complexe :
+#
+# 1. on s'assure de ne pas sélectionner un hôte virtuel pour les
+# adresses communes
+
+RewriteCond %{REQUEST_URI} !^/adresse-commune1/.*
+RewriteCond %{REQUEST_URI} !^/adresse-commune2/.*
+ :
+RewriteCond %{REQUEST_URI} !^/adresse-communeN/.*
+#
+# 2. on vérifie que l'on dispose bien d'un en-tête Host, car
+# actuellement, cette méthode ne peut faire de l'hébergement virtuel
+# qu'avec cet en-tête
+RewriteCond %{HTTP_HOST} !^$
+#
+# 3. mise en minuscules du nom d'hôte
+RewriteCond ${lowercase:%{HTTP_HOST}|NONE} ^(.+)$
+#
+# 4. recherche ce ce nom d'hôte dans vhost.map et
+# enregistrement de celui-ci seulement s'il s'agit d'un chemin
+# (et non "NONE" en provenance de la condition précédente)
+RewriteCond ${vhost:%1} ^(/.*)$
+#
+# 5. nous pouvons enfin faire correspondre l'URL avec la racine des
+# documents correspondant au serveur virtuel approprié et enregistrer
+# ce dernier à des fins de journalisation
+RewriteRule ^/(.*)$ %1/$1 [E=VHOST:${lowercase:%{HTTP_HOST}}]
+ :
+</pre></example>
+ </dd>
+ </dl>
+
+ </section>
+
+ <section id="host-deny">
+
+ <title>Interdiction d'hôtes</title>
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Comment interdire l'accès à notre serveur à une liste
+ d'hôtes ?</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>Pour Apache >= 1.3b6 :</p>
+
+<example><pre>
+RewriteEngine on
+RewriteMap hôtes-interdits txt:/chemin/vers/hôtes-interdits
+RewriteCond ${hôtes-interdits:%{REMOTE_HOST}|NOT-FOUND} !=NOT-FOUND [OR]
+RewriteCond ${hôtes-interdits:%{REMOTE_ADDR}|NOT-FOUND} !=NOT-FOUND
+RewriteRule ^/.* - [F]
+</pre></example>
+
+ <p>Pour Apache <= 1.3b6 :</p>
+
+<example><pre>
+RewriteEngine on
+RewriteMap hôtes-interdits txt:/chemin/vers/hôtes-interdits
+RewriteRule ^/(.*)$ ${hôtes-interdits:%{REMOTE_HOST}|NOT-FOUND}/$1
+RewriteRule !^NOT-FOUND/.* - [F]
+RewriteRule ^NOT-FOUND/(.*)$ ${hôtes-interdits:%{REMOTE_ADDR}|NOT-FOUND}/$1
+RewriteRule !^NOT-FOUND/.* - [F]
+RewriteRule ^NOT-FOUND/(.*)$ /$1
+</pre></example>
+
+<example><pre>
+##
+## hosts.deny
+##
+## ATTENTION! Ceci est une table de correspondances, pas une liste,
+## même si on l'utilise en tant que telle. mod_rewrite l'interprète
+## comme un ensemble de paires clé/valeur ; chaque entrée doit donc
+## au moins posséder une valeur fictive "-".
+##
+
+193.102.180.41 -
+bsdti1.sdm.de -
+192.76.162.40 -
+</pre></example>
+ </dd>
+ </dl>
+
+ </section>
+
+ <section id="proxy-deny">
+
+ <title>Interdiction du mandataire</title>
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Comment interdire l'utilisation du mandataire d'Apache pour
+ un certain hôte, ou même seulement pour un utilisateur
+ de cet hôte ?</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>Nous devons tout d'abord nous assurer que
+ <module>mod_rewrite</module> arrive après(!)
+ <module>mod_proxy</module> dans le fichier de configuration
+ lors de la compilation du serveur web Apache. De cette façon,
+ il est appelé <em>avant</em> <module>mod_proxy</module>. Nous
+ pouvons ensuite définir cette règle pour une interdiction
+ dépendant de l'hôte :</p>
+
+<example><pre>
+RewriteCond %{REMOTE_HOST} <strong>^hôte-à-rejeter\.mon-domaine\.com$</strong>
+RewriteRule !^http://[^/.]\.mon-domaine.com.* - [F]
+</pre></example>
+
+ <p>...et celle-ci pour une interdiction dépendant de
+ utilisateur@hôte :</p>
+
+<example><pre>
+RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} <strong>^utilisateur-à-
+rejeter@hôte-à-rejeter\.mon-domaine\.com$</strong>
+RewriteRule !^http://[^/.]\.mon-domaine.com.* - [F]
+</pre></example>
+ </dd>
+ </dl>
+
+ </section>
+
+ <section id="special-authentication">
+
+ <title>Variante particulière d'authentification</title>
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>On a parfois besoin d'une authentification très
+ particulière, par exemple une authentification qui vérifie la
+ présence d'un utilisateur dans une liste explicitement
+ définie. Seuls ceux qui sont présents dans la liste se voient
+ accorder un accès, et ceci sans avoir à
+ s'identifier/authentifier (comme c'est le cas avec une
+ authentification de base via <module>mod_auth</module>).</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>On définit une liste de conditions de réécriture pour
+ interdire l'accès à tout le monde, sauf aux utilisateurs
+ autorisés :</p>
+
+<example><pre>
+RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} <strong>!^ami1@client1.quux-corp\.com$</strong>
+RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} <strong>!^ami2</strong>@client2.quux-corp\.com$
+RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} <strong>!^ami3</strong>@client3.quux-corp\.com$
+RewriteRule ^/~quux/seulement-pour-les-amis/ - [F]
+</pre></example>
+ </dd>
+ </dl>
+
+ </section>
+
+ <section id="referer-deflector">
+
+ <title>Redirection basée sur le référent</title>
+
+ <dl>
+ <dt>Description :</dt>
+
+ <dd>
+ <p>Comment écrire un programme souple qui redirige certaines
+ URLs en se basant sur l'en-tête HTTP "Referer", et peut être
+ configuré avec autant de pages de référence
+ que l'on veut ?</p>
+ </dd>
+
+ <dt>Solution :</dt>
+
+ <dd>
+ <p>On utilise le jeu de règles vraiment astucieux suivant :</p>
+
+<example><pre>
+RewriteMap deflector txt:/chemin/vers/deflector.map
+
+RewriteCond %{HTTP_REFERER} !=""
+RewriteCond ${deflector:%{HTTP_REFERER}} ^-$
+RewriteRule ^.* %{HTTP_REFERER} [R,L]
+
+RewriteCond %{HTTP_REFERER} !=""
+RewriteCond ${deflector:%{HTTP_REFERER}|NOT-FOUND} !=NOT-FOUND
+RewriteRule ^.* ${deflector:%{HTTP_REFERER}} [R,L]
+</pre></example>
+
+ <p>... en association avec la table de réécriture
+ correspondante :</p>
+
+<example><pre>
+##
+## deflector.map
+##
+
+http://www.mauvais-sujets.com/mauvais/index.html -
+http://www.mauvais-sujets.com/mauvais/index2.html -
+http://www.mauvais-sujets.com/mauvais/index3.html http://quelque-part.com/
+</pre></example>
+
+ <p>Les requêtes sont redirigées vers la page de référence
+ (lorsque la valeur correspondant à la clé extraite de la table
+ de correspondances est égale à "<code>-</code>"), ou vers une
+ URL spécifique (lorsqu'une URL est définie dans la table de
+ correspondances comme second argument).</p>
+ </dd>
+ </dl>
+
+ </section>
+
+</manualpage>
+
<variants>
<variant>en</variant>
+ <variant>fr</variant>
</variants>
</metafile>
URI: rewrite_tech.html.en
Content-Language: en
Content-type: text/html; charset=ISO-8859-1
+
+URI: rewrite_tech.html.fr
+Content-Language: fr
+Content-type: text/html; charset=ISO-8859-1
--- /dev/null
+<?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">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr"><head><!--
+ 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" />
+<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" />
+<link href="../images/favicon.ico" rel="shortcut icon" /></head>
+<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>
+<img alt="" src="../images/feather.gif" /></div>
+<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
+<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/rewrite_tech.html" hreflang="en" rel="alternate" title="English"> en </a> |
+<a href="../fr/rewrite/rewrite_tech.html" title="Français"> fr </a></p>
+</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="#Internal">Fonctionnement interne</a></li>
+<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</a></li><li><a href="rewrite_intro.html">Introduction à mod_rewrite</a></li><li><a href="rewrite_guide.html">Guide de réécriture - exemples
+utiles</a></li><li><a href="rewrite_guide_advanced.html">Guide de réécriture
+avancée - exemples utiles avancés</a></li></ul></div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="Internal" id="Internal">Fonctionnement interne</a></h2>
+
+ <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>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="InternalAPI" id="InternalAPI">Phases de l'API</a></h2>
+
+ <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>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<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/mod_rewrite_fig1.gif" width="428" height="385" alt="[Nécessite le mode graphique pour l'affichage]" /><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/rewrite_tech.html" hreflang="en" rel="alternate" title="English"> en </a> |
+<a href="../fr/rewrite/rewrite_tech.html" title="Français"> fr </a></p>
+</div><div id="footer">
+<p class="apache">Copyright 2009 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>
\ No newline at end of file
--- /dev/null
+<?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 : 636043 -->
+<!-- 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="rewrite_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</a></seealso>
+<seealso><a href="rewrite_intro.html">Introduction à mod_rewrite</a></seealso>
+<seealso><a href="rewrite_guide.html">Guide de réécriture - exemples
+utiles</a></seealso>
+<seealso><a href="rewrite_guide_advanced.html">Guide de réécriture
+avancée - exemples utiles avancés</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>
+</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/mod_rewrite_fig1.gif" width="428"
+ height="385" alt="[Nécessite le mode graphique pour
+ l'affichage]" /><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>
+
+</section>
+
+
+</manualpage>
+
<variants>
<variant>en</variant>
+ <variant>fr</variant>
</variants>
</metafile>
projects / apache / commitdiff