rewrite_guide.xml.fr revision bd2feb86ee6d8c91ecd992138ceb96a7069a5578
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!-- English Revision : 774161 -->
<!-- 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
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.xml.meta">
<parentdocument href="./">Rewrite</parentdocument>
<title>Guide de réécriture des URLs</title>
<summary>
<p>Ce document complète la <a
href="/mod/mod_rewrite.html">documentation de référence</a> du
module <module>mod_rewrite</module>. Il décrit de quelle manière on
peut utiliser le module Apache <module>mod_rewrite</module> pour
résoudre les problèmes typiques relatifs aux URLs auxquels les
webmasters sont souvent confrontés. La résolution de chaque problème
par la configuration des jeux de règles de réécriture d'URLs fait
l'objet d'une description détaillée.</p>
<note type="warning">ATTENTION : l'adaptation des exemples à votre
situation en fonction de la configuration de votre serveur pourra
s'avérer nécessaire, par exemple l'ajout du drapeau
<code>[PT]</code> si vous utilisez les modules
<module>mod_alias</module>, <module>mod_userdir</module>, etc... Un
jeu de règles défini dans le contexte du serveur devra aussi être
adapté pour être utilisé dans un contexte <code>.htaccess</code>.
Efforcez-vous toujours de bien comprendre l'effet produit par un jeu
de règles avant de l'utiliser, ce qui pourra vous éviter bien des
problèmes.</note>
</summary>
avancé - exemples utiles avancés</a></seealso>
<section id="canonicalurl">
<title>URLs canoniques</title>
<dl>
<dt>Description :</dt>
<dd>
<p>Sur certains serveurs web, une ressource peut être accessible
depuis plusieurs URLs. On trouve en général des URLs canoniques
(qui sont réellement utilisables et distribuables), mais aussi des
URLs à usage interne, ou celles qui ne sont que des raccourcis,
etc... On souhaite que, quelle que soit l'URL que l'utilisateur
a fournie avec sa requête, il ne doit en voir en fin de compte
que la forme canonique.</p>
</dd>
<dt>Solution :</dt>
<dd>
<p>On effectue une redirection HTTP externe pour toutes les URLs
non canoniques afin de les rendre compréhensibles au navigateur
et ceci pour toutes les requêtes sous-jacentes. Dans l'exemple de
jeux de règles ci-dessous, <code>/~user</code> est remplacé par
<example><pre>
RewriteRule ^/<strong>~</strong>([^/]+)/?(.*) /<strong>u</strong>/$1/$2 [<strong>R</strong>]
RewriteRule ^/u/(<strong>[^/]+</strong>)$ /$1/$2<strong>/</strong> [<strong>R</strong>]
</pre></example>
</dd>
</dl>
</section>
<section id="canonicalhost"><title>Noms d'hôtes canoniques</title>
<dl>
<dt>Description :</dt>
<dd>Le but de cette règle est de préférer l'utilisation d'un nom
d'hôte particulier par rapport à d'autres noms d'hôte utilisables
pour atteindre le même site. Par exemple, si vous voulez
de ce style.</dd>
<dt>Solution :</dt>
<dd>
<p>Pour les sites écoutant sur un port autre que 80:</p>
<example><pre>
RewriteCond %{HTTP_HOST} !^www\.exemple\.com [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteCond %{SERVER_PORT} !^80$
RewriteRule ^/?(.*) http://www.exemple.com:%{SERVER_PORT}/$1
[L,R,NE]
</pre></example>
<p>Et pour un site écoutant sur le port 80</p>
<example><pre>
RewriteCond %{HTTP_HOST} !^www\.exemple\.com [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/?(.*) http://www.exemple.com/$1 [L,R,NE]
</pre></example>
<p>
Si vous souhaitez que cette règle s'applique à tous les noms de
domaine - en d'autres termes, si vous voulez rediriger
le jeu de règles suivants :</p>
<example><pre>
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/?(.*) http://www.%{HTTP_HOST}/$1 [L,R,NE]
</pre></example>
<p>
Vous pouvez utiliser ce jeu de règles aussi bien dans le fichier
de configuration de votre serveur principal que dans un fichier
<code>.htaccess</code> placé dans le répertoire défini par la
directive <directive
module="core">DocumentRoot</directive> du serveur.</p>
</dd>
</dl>
</section>
<section id="moveddocroot">
<title><code>DocumentRoot</code>déplacé</title>
<dl>
<dt>Description :</dt>
<dd>
<p>En général, la directive <directive
module="core">DocumentRoot</directive> correspond directement à l'URL
"<code>/</code>" du serveur web. Mais souvent, les données qui s'y
trouvent ne sont pas de la première priorité. Par exemple, il peut être
intéressant, pour les visiteurs qui entrent sur le site pour la première
fois, d'être redirigés vers un sous-répertoire particulier
<code>/a-propos-de/</code>. Pour ce faire, on peut utiliser le jeu de
règles suivant :</p>
</dd>
<dt>Solution :</dt>
<dd>
<p>On redirige l'URL <code>/</code> vers
<code>/a-propos-de/</code>:
</p>
<example><pre>
RewriteEngine on
RewriteRule <strong>^/$</strong> /a-propos-de/ [<strong>R</strong>]
</pre></example>
<p>Notez que le même effet peut être obtenu à l'aide de la directive
<directive module="mod_alias">RedirectMatch</directive> :</p>
<example>
RedirectMatch ^/$ http://exemple.com/apropos/
</example>
<p>Notez aussi que cet exemple ne réécrit que l'URL racine. En d'autres
mais ne réécrira pas une requête pour
la racine de vos documents - c'est à dire si tous vos contenus se
trouvent dans ce sous-répertoire, il vaut mieux simplement modifier
votre directive <directive module="core">DocumentRoot</directive> que de
procéder à une réécriture d'URLs.</p>
</dd>
</dl>
</section>
<section id="trailingslash">
<title>Problème du slash de fin</title>
<dl>
<dt>Description :</dt>
<dd><p>La plupart des problèmes de "slash de fin" peuvent être
résolus grâce aux techniques décrites dans ce <a
href="http://httpd.apache.org/docs/misc/FAQ-E.html#set-servername">sujet
de la FAQ</a>. Cependant, dans certaines situations où l'absence de slash de fin
peut rendre une URL inopérante, l'utilisation de
mod_rewrite s'avère nécessaire. Le cas peut se présenter, par exemple,
après une série complexe de règles de réécriture.</p>
</dd>
<dt>Solution :</dt>
<dd>
<p>La solution à ce problème subtil consiste à laisser le
serveur ajouter le slash de fin automatiquement. Pour y
parvenir, il faut utiliser une redirection externe, afin que
le navigateur demande correctement les images sous-jacentes,
etc... Une réécriture en interne ne fonctionnerait que pour la
page du répertoire, mais échouerait pour toute image incluse
dans cette page via des liens relatifs, car le navigateur
demanderait un objet inséré. Par exemple, une requête pour
externe !</p>
<p>Pour y parvenir, on peut utiliser des règles de ce style :</p>
<example><pre>
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^foo<strong>$</strong> foo<strong>/</strong> [<strong>R</strong>]
</pre></example>
<p>Vous pouvez aussi ajouter ce qui suit dans un fichier
<code>.htaccess</code> situé dans le répertoire contenant la
ressource. Notez cependant que cela augmente la charge du processeur.</p>
<example><pre>
RewriteEngine on
RewriteBase /~quux/
RewriteCond %{REQUEST_FILENAME} <strong>-d</strong>
RewriteRule ^(.+<strong>[^/]</strong>)$ $1<strong>/</strong> [R]
</pre></example>
</dd>
</dl>
</section>
<section id="movehomedirs">
<title>Déplacement des répertoires home vers un autre serveur</title>
<dl>
<dt>Description :</dt>
<dd>
<p>De nombreux webmasters ont demandé comment résoudre le
problème suivant : ils voudraient tout simplement rediriger
les répertoires home d'un serveur web vers un autre serveur
web. Cette situation se présente en général lorsqu'on installe
un nouveau serveur web destiné à terme à en remplacer un autre
plus ancien.</p>
</dd>
<dt>Solution :</dt>
<dd>
<p>Avec <module>mod_rewrite</module>, la solution est
évidente. Sur l'ancien serveur web, on redirige simplement
<example><pre>
RewriteEngine on
RewriteRule ^/~(.+) http://<strong>nouveau-serveur</strong>/~$1 [R,L]
</pre></example>
</dd>
</dl>
</section>
<section id="multipledirs">
<title>Recherche de pages dans plus d'un répertoire</title>
<dl>
<dt>Description :</dt>
<dd>
<p>Le serveur web doit parfois rechercher des pages dans plus
d'un répertoire. Dans ce cas, les vues multiples ou autres
techniques similaires ne sont d'aucun secours.</p>
</dd>
<dt>Solution :</dt>
<dd>
<p>On définit explicitement un jeu de règles qui recherche les
fichiers dans les répertoires.</p>
<example><pre>
RewriteEngine on
# on cherche tout d'abord dans dir1/...
# ... et si on trouve, on est content et on arrête :
RewriteCond %{DOCUMENT_ROOT}/<strong>dir1</strong>/%{REQUEST_URI} -f
RewriteRule ^(.+) %{DOCUMENT_ROOT}/<strong>dir1</strong>/$1 [L]
# on cherche ensuite dans dir2/...
# ... et si on trouve, on est content et on arrête :
RewriteCond %{DOCUMENT_ROOT}/<strong>dir2</strong>/%{REQUEST_URI} -f
RewriteRule ^(.+) %{DOCUMENT_ROOT}/<strong>dir2</strong>/$1 [L]
# sinon, on continue la recherche avec d'autres directives Alias
# ou ScriptAlias, etc...
RewriteRule ^(.+) - [PT]
</pre></example>
</dd>
</dl>
</section>
<section id="setenvvars">
<title>Définir des variables d'environnement en fonction de
certaines parties de l'URL</title>
<dl>
<dt>Description :</dt>
<dd>
<p>Comment conserver des informations
d'état d'une requête à l'autre et utiliser l'URL pour les
encoder, sans utiliser d'encapsulateur CGI
pour toutes les pages pour seulement supprimer ces
informations.</p>
</dd>
<dt>Solution :</dt>
<dd>
<p>On utilise une règle de réécriture pour supprimer
l'information d'état et l'enregistrer dans une variable
d'environnement dont on pourra plus tard extraire la valeur
dans XSSI ou CGI. De cette façon, une URL telle que
<code>STATUS</code> aura pour valeur "java".</p>
<example><pre>
RewriteEngine on
RewriteRule ^(.*)/<strong>S=([^/]+)</strong>/(.*) $1/$3 [E=<strong>STATUS:$2</strong>]
</pre></example>
</dd>
</dl>
</section>
<section id="uservhosts">
<title>Hôtes virtuels basés sur l'utilisateur</title>
<dl>
<dt>Description :</dt>
<dd>
<p>Supposons que vous vouliez atteindre la page d'accueil des
utilisateurs sur une même machine au moyen de l'URL
en vous basant
seulement sur les enregistrements DNS de type A, et ceci sans qu'aucun
hôte virtuel ne soit installé sur cette machine.</p>
</dd>
<dt>Solution :</dt>
<dd>
en-tête HTTP Host:, on peut utiliser le jeu de règles suivant
pour réécrire en interne
<example><pre>
RewriteEngine on
RewriteCond %{<strong>HTTP_HOST</strong>} ^www\.<strong>([^.]+)</strong>\.host\.com$
RewriteRule ^(.*) /home/<strong>%1</strong>$1
</pre></example>
<p>Les parenthèses utilisées dans une directive <directive
module="mod_rewrite">RewriteCond</directive> sont capturées dans les
références arrières <code>%1</code>, <code>%2</code>, etc..., alors que
les parenthèses utilisées dans une directive <directive
module="mod_rewrite">RewriteRule</directive> sont capturées dans les
références arrières <code>$1</code>, <code>$2</code>, etc...</p>
</dd>
</dl>
</section>
<section id="redirecthome">
<title>Redirection des répertoires d'accueil pour les étrangers</title>
<dl>
<dt>Description :</dt>
<dd>
<p>On veut rediriger les URLs des répertoires d'accueil vers
l'utilisateur demandeur n'appartient pas au domaine local
situation dans un contexte d'hôtes virtuels.</p>
</dd>
<dt>Solution :</dt>
<dd>
<p>Juste une condition de réécriture :</p>
<example><pre>
RewriteEngine on
RewriteCond %{REMOTE_HOST} <strong>!^.+\.notre-domaine\.com$</strong>
RewriteRule ^(/~.+) http://www.quelque-part.com/$1 [R,L]
</pre></example>
</dd>
</dl>
</section>
<section id="redirectanchors">
<title>Redirection des ancrages</title>
<dl>
<dt>Description :</dt>
<dd>
<p>Par défaut, la redirection vers un ancrage HTML ne fonctionne
pas, car mod_rewrite échappe le caractère <code>#</code> en le
transformant en <code>%23</code>, ce qui rend la redirection
inopérante.</p>
</dd>
<dt>Solution :</dt>
<dd>
<p>On utilise le drapeau <code>[NE]</code> dans la règle
<code>RewriteRule</code>. NE signifie "No Escape".
</p>
</dd>
</dl>
</section>
<section id="time-dependent">
<title>Réécriture dépendant de l'heure</title>
<dl>
<dt>Description :</dt>
<dd>
<p>Lorsqu'il s'agit de distribuer des contenus dont la nature
dépend de l'heure, de nombreux webmasters utilisent encore des
scripts CGI qui redirigent par exemple vers des pages
spécifiques. Comment peut-on y parvenir à tenir compte de
l'heure à l'aide de <module>mod_rewrite</module> ?</p>
</dd>
<dt>Solution :</dt>
<dd>
<p>Il existe de nombreuses variables nommées
<code>TIME_xxx</code> utilisables dans les conditions de
réécriture. Utilisées en conjonction avec les modèles de
comparaison lexicographique spéciaux <code><STRING</code>,
<code>>STRING</code> et <code>=STRING</code>, elles
permettent d'effectuer des redirections dépendant de
l'heure :</p>
<example><pre>
RewriteEngine on
RewriteCond %{TIME_HOUR}%{TIME_MIN} >0700
RewriteCond %{TIME_HOUR}%{TIME_MIN} <1900
RewriteRule ^foo\.html$ foo.jour.html
RewriteRule ^foo\.html$ foo.nuit.html
</pre></example>
créneau horaire <code>07:00-19:00</code>, et le contenu de
fonctionnalité pour une page d'accueil...</p>
</dd>
</dl>
</section>
<section id="backward-compatibility">
<title>Compatibilité ascendante pour une migration de YYYY vers
XXXX</title>
<dl>
<dt>Description :</dt>
<dd>
<p>Comment conférer une compatibilité ascendante aux URLs
(existant encore virtuellement) après avoir migré
c'est à dire après avoir par exemple traduit un lot de
fichiers <code>.html</code> en fichiers <code>.phtml</code>
?</p>
</dd>
<dt>Solution :</dt>
<dd>
<p>On réécrit simplement le nom du fichier en son nom
de base et vérifie s'il existe aussi avec la nouvelle
extension. Si c'est le cas, on utilise ce nom, sinon on
réécrit l'URL sous sa forme originale.</p>
<example><pre>
# jeu de règles assurant une compatibilité ascendante en réécrivant
# existe et document.html n'existe plus
RewriteEngine on
RewriteBase /~quux/
# réécriture du fichier en son nom de base,
# mais garde en mémoire le fait qu'il s'agit
# d'un fichier html
RewriteRule ^(.*)\.html$ $1 [C,E=WasHTML:yes]
# réécrit vers document.phtml s'il existe
# Note : il s'agit d'un exemple de niveau répertoire, si bien que
# %{REQUEST_FILENAME} contient le chemin complet du système de fichier
# tel qu'il a été construit par le serveur.
RewriteCond %{REQUEST_FILENAME}.phtml -f
RewriteRule ^(.*)$ $1.phtml [S=1]
# sinon, restauration du nom de fichier complet original
RewriteCond %{ENV:WasHTML} ^yes$
RewriteRule ^(.*)$ $1.html
</pre></example>
</dd>
</dl>
</section>
<section id="old-to-new">
<title>De l'ancien au nouveau (en interne)</title>
<dl>
<dt>Description :</dt>
<dd>
<p>Supposons que nous ayons récemment renommé la page
maintenant que l'ancienne URL soit toujours valide à des fins
de compatibilité ascendante. En fait, on voudrait que le
changement de nom soit transparent aux utilisateurs de
l'ancienne URL.</p>
</dd>
<dt>Solution :</dt>
<dd>
<p>On réécrit l'ancienne URL en interne vers la nouvelle via
la règle suivante :</p>
<example><pre>
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^<strong>foo</strong>\.html$ <strong>bar</strong>.html
</pre></example>
</dd>
</dl>
</section>
<section id="old-to-new-extern">
<title>De l'ancien au nouveau (en externe)</title>
<dl>
<dt>Description :</dt>
<dd>
<p>Supposons toujours que nous ayons récemment renommé la page
maintenant que l'ancienne URL soit toujours valide à des fins
de compatibilité ascendante. Par contre, nous voulons cette
fois que les utilisateurs de l'ancienne URL soient redirigés
vers la nouvelle, c'est à dire que l'adresse tapée
dans leur navigateur doit aussi être modifiée.</p>
</dd>
<dt>Solution :</dt>
<dd>
<p>On force une redirection HTTP vers la nouvelle URL, ce qui
entraîne une modification de celle du navigateur et aussi de ce
que voit l'utilisateur :</p>
<example><pre>
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^<strong>foo</strong>\.html$ <strong>bar</strong>.html [<strong>R</strong>]
</pre></example>
</dd>
</dl>
</section>
<section id="static-to-dynamic">
<title>De statique à dynamique</title>
<dl>
<dt>Description :</dt>
<dd>
transparente, c'est à dire sans en avertir le
</dd>
<dt>Solution :</dt>
<dd>
<p>On réécrit simplement l'URL en script CGI et force le
gestionnaire de contenu à <strong>cgi-script</strong> de façon
à ce que le script s'exécute en tant que programme CGI.
en interne à l'invocation de
<example><pre>
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^foo\.<strong>html</strong>$ foo.<strong>cgi</strong> [H=<strong>cgi-script</strong>]
</pre></example>
</dd>
</dl>
</section>
<section id="blocking-of-robots">
<title>Blocage des robots</title>
<dl>
<dt>Description :</dt>
<dd>
<p>Comment empêcher un robot vraiment gênant de collecter les
pages d'une partie spécifique du site web ? Un fichier
d'Exclusion des Robots" ne suffit généralement pas à en venir
à bout.</p>
</dd>
<dt>Solution :</dt>
<dd>
<p>On utilise un jeu de règles qui interdit les URLs de la
(peut-être une partie du serveur avec une arborescence très
développée à travers laquelle le parcours du
robot induirait une charge importante pour le serveur). Nous
devons nous assurer de n'interdire l'accès qu'à ce robot
particulier, c'est à dire qu'il ne suffit pas d'interdire
l'accès à l'hôte sur lequel le robot fonctionne, ce qui
bloquerait aussi les utilisateurs de cet hôte. Pour y
parvenir, on tient aussi compte des informations contenues
dans l'en-tête HTTP User-Agent.</p>
<example><pre>
RewriteCond %{HTTP_USER_AGENT} ^<strong>NameOfBadRobot</strong>.*
RewriteCond %{REMOTE_ADDR} ^<strong>123\.45\.67\.[8-9]</strong>$
</pre></example>
</dd>
</dl>
</section>
<section id="blocked-inline-images">
<title>Blocage du référencement à chaud (Hotlinking) d'images</title>
<dl>
<dt>Description :</dt>
<dd>
<p>Cette technique vous permet d'interdire à d'autres sites
d'inclure directement vos images dans leurs pages. On fait
souvent référence à cette pratique sous le nom de
référencement à chaud (Hotlinking) qui entraîne l'utilisation
de votre bande passante pour servir des contenus faisant
partie du site de quelqu'un d'autre.</p>
</dd>
<dt>Solution :</dt>
<dd>
<p>Cette technique repose sur la valeur de la variable
optionnelle <code>HTTP_REFERER</code>. Certaines personnes
pourront donc contourner cette limitation. Pour la plupart des
utilisateurs cependant, la requête échouera, en ce sens que
l'image ne sera pas affichée depuis le site tiers.</p>
<p>Il y a plusieurs manières de gérer cette situation.</p>
<p>Dans le premier exemple, nous rejetons tout simplement la
requête si elle ne provenait pas d'une page appartenant à notre
site. Pour les besoins de cet exemple, nous supposons que le nom
<example><pre>
RewriteCond %{HTTP_REFERER} <strong>!^$</strong>
RewriteCond %{HTTP_REFERER} !www.example.com [NC]
RewriteRule <strong>\.(gif|jpg|png)$</strong> - [F,NC]
</pre></example>
<p>Dans le second exemple, plutôt que de rejeter la requête,
nous affichons une autre image à la place.</p>
<example><pre>
RewriteCond %{HTTP_REFERER} <strong>!^$</strong>
RewriteCond %{HTTP_REFERER} !www.example.com [NC]
</pre></example>
<p>Dans le troisième exemple, nous redirigeons la requête vers
une image appartenant à un site tiers.</p>
<example><pre>
RewriteCond %{HTTP_REFERER} <strong>!^$</strong>
RewriteCond %{HTTP_REFERER} !www.example.com [NC]
</pre></example>
<p>De tous ces exemples, les deux derniers semblent les plus
efficaces pour faire en sorte que les gens arrêtent de
référencer vos images à chaud, car il ne verront pas les images
qu'ils s'attendent à voir.</p>
</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 à un
certain hôte, ou même à un utilisateur d'un certain hôte ?</p>
</dd>
<dt>Solution :</dt>
<dd>
<p>Nous devons tout d'abord nous assurer que
<module>mod_rewrite</module> se situe en dessous (!) de
<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 alors utiliser la règle suivante pour une interdiction
concernant un hôte...</p>
<example><pre>
RewriteCond %{REMOTE_HOST} <strong>^mauvais-hôte\.mon-domaine\.com$</strong>
RewriteRule !^http://[^/.]\.mon-domaine.com.* - [F]
</pre></example>
<p>...et celle-ci pour une interdiction concernant un
utilisateur d'un certain hôte :</p>
<example><pre>
RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST}
<strong>^mauvais-sujet@mauvais-hôte\.mon-domaine\.com$</strong>
RewriteRule !^http://[^/.]\.mon-domaine.com.* - [F]
</pre></example>
</dd>
</dl>
</section>
<section id="external-rewriting">
<title>Moteur de réécriture externe</title>
<dl>
<dt>Description :</dt>
<dd>
<p>Une question de la Faq : comment résoudre le problème
devoir y apporter de solution...</p>
</dd>
<dt>Solution :</dt>
<dd>
<p>Utiliser une <directive module="mod_rewrite"
>RewriteMap</directive> ou table de réécriture externe, c'est
à dire un programme qui agit de la même façon qu'une
<directive module="mod_rewrite">RewriteMap</directive>. Il
doit être lancé une fois au démarrage d'Apache, recevoir les
URLs des requêtes sur <code>STDIN</code>, et restituer l'URL
résultante (en général réécrite) sur <code>STDOUT</code> (dans
cet ordre !).</p>
<example><pre>
RewriteEngine on
RewriteRule ^/~quux/(.*)$ /~quux/<strong>${quux-table:$1}</strong>
</pre></example>
<example><pre>
# de provoquer des bouclages infinis pour le serveur Apache
$| = 1;
# lit les URLs (une par ligne) depuis stdin et
# génère l'URL transformée sur stdout
# read URLs one per line from stdin and
# generate substitution URL on stdout
while (<>) {
s|^foo/|bar/|;
print $_;
}
</pre></example>
<p>Ceci n'est qu'un exemple de démonstration qui ne fait que
la substitution que vous voulez. Notez cependant que si de
tels programmes peuvent aussi être <strong>utilisés</strong>
par un utilisateur standard, seul l'administrateur du système
peut les <strong>écrire</strong>.</p>
</dd>
</dl>
</section>
</manualpage>