www/apache
1
0
Fork 0
mirror of https://github.com/apache/httpd.git synced 2025-07-29 09:01:18 +03:00
Code Activity
Files
84a9a6834fed235dedb65eda45f271fca4dc2b51
apache/docs/manual/rewrite/rewrite_guide.html.fr
Rich Bowen b134f9aac1 2009 -> 2010 in the copyright statement. Nobody seems to know if this is 
actually necessary, but it's sort of an annual tradition. We think
tradition is pretty important.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@895795 13f79535-47bb-0310-9956-ffa450edef68
2010-01-04 21:41:42 +00:00

870 lines
34 KiB
Plaintext
Raw Blame History

<?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 - 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="&lt;-" alt="&lt;-" src="/images/left.gif" /></a></div>
<div id="path">
<a href="http://www.apache.org/">Apache</a> &gt; <a href="http://httpd.apache.org/">Serveur HTTP</a> &gt; <a href="http://httpd.apache.org/docs/">Documentation</a> &gt; <a href="/">Version 2.3</a> &gt; <a href="./">Rewrite</a></div><div id="page-content"><div id="preamble"><h1>Guide de réécriture des URLs</h1>
<div class="toplang">
<p><span>Langues Disponibles: </span></p>
</div>
<p>Ce document complète 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 de quelle manière on
peut utiliser le module Apache <code class="module"><a href="/mod/mod_rewrite.html">mod_rewrite</a></code> 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>
<div class="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
<code class="module"><a href="/mod/mod_alias.html">mod_alias</a></code>, <code class="module"><a href="/mod/mod_userdir.html">mod_userdir</a></code>, 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.</div>
</div>
<div id="quickview"><ul id="toc"><li><img alt="" src="/images/down.gif" /> <a href="#canonicalurl">URLs canoniques</a></li>
<li><img alt="" src="/images/down.gif" /> <a href="#canonicalhost">Noms d'hôtes canoniques</a></li>
<li><img alt="" src="/images/down.gif" /> <a href="#moveddocroot"><code>DocumentRoot</code>déplacé</a></li>
<li><img alt="" src="/images/down.gif" /> <a href="#trailingslash">Problème du slash de fin</a></li>
<li><img alt="" src="/images/down.gif" /> <a href="#movehomedirs">Déplacement des répertoires home vers un autre serveur</a></li>
<li><img alt="" src="/images/down.gif" /> <a href="#multipledirs">Recherche de pages dans plus d'un répertoire</a></li>
<li><img alt="" src="/images/down.gif" /> <a href="#setenvvars">Définir des variables d'environnement en fonction de
certaines parties de l'URL</a></li>
<li><img alt="" src="/images/down.gif" /> <a href="#uservhosts">Hôtes virtuels basés sur l'utilisateur</a></li>
<li><img alt="" src="/images/down.gif" /> <a href="#redirecthome">Redirection des répertoires d'accueil pour les étrangers</a></li>
<li><img alt="" src="/images/down.gif" /> <a href="#redirectanchors">Redirection des ancrages</a></li>
<li><img alt="" src="/images/down.gif" /> <a href="#time-dependent">Réécriture dépendant de l'heure</a></li>
<li><img alt="" src="/images/down.gif" /> <a href="#backward-compatibility">Compatibilité ascendante pour une migration de YYYY vers
XXXX</a></li>
<li><img alt="" src="/images/down.gif" /> <a href="#old-to-new">De l'ancien au nouveau (en interne)</a></li>
<li><img alt="" src="/images/down.gif" /> <a href="#old-to-new-extern">De l'ancien au nouveau (en externe)</a></li>
<li><img alt="" src="/images/down.gif" /> <a href="#static-to-dynamic">De statique à dynamique</a></li>
<li><img alt="" src="/images/down.gif" /> <a href="#blocking-of-robots">Blocage des robots</a></li>
<li><img alt="" src="/images/down.gif" /> <a href="#blocked-inline-images">Blocage du référencement à chaud (Hotlinking) d'images</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="#external-rewriting">Moteur de réécriture externe</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="intro.html">Introduction à mod_rewrite</a></li><li><a href="rewrite_guide_advanced.html">Guide de réécriture
avancé - exemples utiles avancés</a></li><li><a href="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="canonicalurl" id="canonicalurl">URLs canoniques</a></h2>
<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
l'expression canonique <code>/u/user</code>, et une éventuelle
absence du slash à la fin de <code>/u/user</code> est corrigée.</p>
<div class="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></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="canonicalhost" id="canonicalhost">Noms d'hôtes canoniques</a></h2>
<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
utiliser <strong>www.example.com</strong> à la place de
<strong>example.com</strong>, vous devez utiliser une solution
de ce style.</dd>
<dt>Solution :</dt>
<dd>
<p>Pour les sites écoutant sur un port autre que 80:</p>
<div class="example"><pre>
RewriteCond %{HTTP_HOST} !^www\.exemple\.com [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteCond %{SERVER_PORT} !^80$
RewriteRule ^/?(.*) http://www.example.com:%{SERVER_PORT}/$1
[L,R,NE]
</pre></div>
<p>Et pour un site écoutant sur le port 80</p>
<div class="example"><pre>
RewriteCond %{HTTP_HOST} !^www\.exemple\.com [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/?(.*) http://www.example.com/$1 [L,R,NE]
</pre></div>
<p>
Si vous souhaitez que cette règle s'applique à tous les noms de
domaine - en d'autres termes, si vous voulez rediriger
<strong>example.com</strong> vers
<strong>www.example.com</strong> pour toutes les valeurs
possibles de <strong>example.com</strong>, vous pouvez utiliser
le jeu de règles suivants :</p>
<div class="example"><pre>
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/?(.*) http://www.%{HTTP_HOST}/$1 [L,R,NE]
</pre></div>
<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 <code class="directive"><a href="/mod/core.html#documentroot">DocumentRoot</a></code> du serveur.</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="moveddocroot" id="moveddocroot"><code>DocumentRoot</code>déplacé</a></h2>
<dl>
<dt>Description :</dt>
<dd>
<p>En général, la directive <code class="directive"><a href="/mod/core.html#documentroot">DocumentRoot</a></code> 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>
<div class="example"><pre>
RewriteEngine on
RewriteRule <strong>^/$</strong> /a-propos-de/ [<strong>R</strong>]
</pre></div>
<p>Notez que le même effet peut être obtenu à l'aide de la directive
<code class="directive"><a href="/mod/mod_alias.html#redirectmatch">RedirectMatch</a></code> :</p>
<div class="example"><p><code>
RedirectMatch ^/$ http://example.com/apropos/
</code></p></div>
<p>Notez aussi que cet exemple ne réécrit que l'URL racine. En d'autres
termes, il réécrit une requête pour <code>http://example.com/</code>,
mais ne réécrira pas une requête pour
<code>http://example.com/page.html</code>. En fait, si vous avez modifié
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 <code class="directive"><a href="/mod/core.html#documentroot">DocumentRoot</a></code> que de
procéder à une réécriture d'URLs.</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="trailingslash" id="trailingslash">Problème du slash de fin</a></h2>
<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
<code>image.gif</code> dans <code>/~quux/foo/index.html</code>
deviendrait <code>/~quux/image.gif</code> sans la redirection
externe !</p>
<p>Pour y parvenir, on peut utiliser des règles de ce style :</p>
<div class="example"><pre>
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^foo<strong>$</strong> foo<strong>/</strong> [<strong>R</strong>]
</pre></div>
<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>
<div class="example"><pre>
RewriteEngine on
RewriteBase /~quux/
RewriteCond %{REQUEST_FILENAME} <strong>-d</strong>
RewriteRule ^(.+<strong>[^/]</strong>)$ $1<strong>/</strong> [R]
</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="movehomedirs" id="movehomedirs">Déplacement des répertoires home vers un autre serveur</a></h2>
<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 <code class="module"><a href="/mod/mod_rewrite.html">mod_rewrite</a></code>, la solution est
évidente. Sur l'ancien serveur web, on redirige simplement
toutes les URLs du style <code>/~user/chemin</code> vers
<code>http://nouveau-serveur/~user/chemin</code>.</p>
<div class="example"><pre>
RewriteEngine on
RewriteRule ^/~(.+) http://<strong>nouveau-serveur</strong>/~$1 [R,L]
</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="multipledirs" id="multipledirs">Recherche de pages dans plus d'un répertoire</a></h2>
<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>
<div class="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></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="setenvvars" id="setenvvars">Définir des variables d'environnement en fonction de
certaines parties de l'URL</a></h2>
<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>/foo/S=java/bar/</code> sera traduite en
<code>/foo/bar/</code> et la variable d'environnement
<code>STATUS</code> aura pour valeur "java".</p>
<div class="example"><pre>
RewriteEngine on
RewriteRule ^(.*)/<strong>S=([^/]+)</strong>/(.*) $1/$3 [E=<strong>STATUS:$2</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="uservhosts" id="uservhosts">Hôtes virtuels basés sur l'utilisateur</a></h2>
<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
<code>www.<strong>nom-utilisateur</strong>.hôte.domaine.com</code>,
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>
<p>Dans le cas des requêtes HTTP/1.0, il n'y a pas de solution
; par contre, avec une requête HTTP/1.1 qui contient un
en-tête HTTP Host:, on peut utiliser le jeu de règles suivant
pour réécrire en interne
<code>http://www.nom-utilisateur.hôte.com/chemin</code> vers
<code>/home/nom-utilisateur/chemin</code> :</p>
<div class="example"><pre>
RewriteEngine on
RewriteCond %{<strong>HTTP_HOST</strong>} ^www\.<strong>([^.]+)</strong>\.host\.com$
RewriteRule ^(.*) /home/<strong>%1</strong>$1
</pre></div>
<p>Les parenthèses utilisées dans une directive <code class="directive"><a href="/mod/mod_rewrite.html#rewritecond">RewriteCond</a></code> 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 <code class="directive"><a href="/mod/mod_rewrite.html#rewriterule">RewriteRule</a></code> sont capturées dans les
références arrières <code>$1</code>, <code>$2</code>, etc...</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="redirecthome" id="redirecthome">Redirection des répertoires d'accueil pour les étrangers</a></h2>
<dl>
<dt>Description :</dt>
<dd>
<p>On veut rediriger les URLs des répertoires d'accueil vers
un autre serveur <code>www.quelque-part.com</code> lorsque
l'utilisateur demandeur n'appartient pas au domaine local
<code>notre-domaine.com</code>. On rencontre parfois cette
situation dans un contexte d'hôtes virtuels.</p>
</dd>
<dt>Solution :</dt>
<dd>
<p>Juste une condition de réécriture :</p>
<div class="example"><pre>
RewriteEngine on
RewriteCond %{REMOTE_HOST} <strong>!^.+\.notre-domaine\.com$</strong>
RewriteRule ^(/~.+) http://www.quelque-part.com/$1 [R,L]
</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="redirectanchors" id="redirectanchors">Redirection des ancrages</a></h2>
<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>
</div><div class="top"><a href="#page-header"><img alt="top" src="/images/up.gif" /></a></div>
<div class="section">
<h2><a name="time-dependent" id="time-dependent">Réécriture dépendant de l'heure</a></h2>
<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 <code class="module"><a href="/mod/mod_rewrite.html">mod_rewrite</a></code> ?</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>&lt;STRING</code>,
<code>&gt;STRING</code> et <code>=STRING</code>, elles
permettent d'effectuer des redirections dépendant de
l'heure :</p>
<div class="example"><pre>
RewriteEngine on
RewriteCond %{TIME_HOUR}%{TIME_MIN} &gt;0700
RewriteCond %{TIME_HOUR}%{TIME_MIN} &lt;1900
RewriteRule ^foo\.html$ foo.jour.html
RewriteRule ^foo\.html$ foo.nuit.html
</pre></div>
<p>Avec cet exemple, l'URL <code>foo.html</code> renvoie
le contenu de <code>foo.jour.html</code> durant le
créneau horaire <code>07:00-19:00</code>, et le contenu de
<code>foo.nuit.html</code> le reste du temps. Agréable
fonctionnalité pour une page d'accueil...</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="backward-compatibility" id="backward-compatibility">Compatibilité ascendante pour une migration de YYYY vers
XXXX</a></h2>
<dl>
<dt>Description :</dt>
<dd>
<p>Comment conférer une compatibilité ascendante aux URLs
(existant encore virtuellement) après avoir migré
<code>document.YYYY</code> vers <code>document.XXXX</code>,
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>
<div class="example"><pre>
# jeu de règles assurant une compatibilité ascendante en réécrivant
# document.html en document.phtml si et seulement si document.phtml
# 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></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="old-to-new" id="old-to-new">De l'ancien au nouveau (en interne)</a></h2>
<dl>
<dt>Description :</dt>
<dd>
<p>Supposons que nous ayons récemment renommé la page
<code>foo.html</code> en <code>bar.html</code>, et voulions
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>
<div class="example"><pre>
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^<strong>foo</strong>\.html$ <strong>bar</strong>.html
</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="old-to-new-extern" id="old-to-new-extern">De l'ancien au nouveau (en externe)</a></h2>
<dl>
<dt>Description :</dt>
<dd>
<p>Supposons toujours que nous ayons récemment renommé la page
<code>foo.html</code> en <code>bar.html</code>, et voulions
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>
<div class="example"><pre>
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^<strong>foo</strong>\.html$ <strong>bar</strong>.html [<strong>R</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="static-to-dynamic" id="static-to-dynamic">De statique à dynamique</a></h2>
<dl>
<dt>Description :</dt>
<dd>
<p>Comment transformer une page statique <code>foo.html</code>
en sa variante dynamique <code>foo.cgi</code> de manière
transparente, c'est à dire sans en avertir le
navigateur/utilisateur.</p>
</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.
Ainsi, une requête vers <code>/~quux/foo.html</code> conduit
en interne à l'invocation de
<code>/~quux/foo.cgi</code>.</p>
<div class="example"><pre>
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^foo\.<strong>html</strong>$ foo.<strong>cgi</strong> [H=<strong>cgi-script</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="blocking-of-robots" id="blocking-of-robots">Blocage des robots</a></h2>
<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
<code>/robots.txt</code> comportant les entrées du "Protocole
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
partie du site web concernée <code>/~quux/foo/arc/</code>
(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>
<div class="example"><pre>
RewriteCond %{HTTP_USER_AGENT} ^<strong>NameOfBadRobot</strong>.*
RewriteCond %{REMOTE_ADDR} ^<strong>123\.45\.67\.[8-9]</strong>$
RewriteRule ^<strong>/~quux/foo/arc/</strong>.+ - [<strong>F</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="blocked-inline-images" id="blocked-inline-images">Blocage du référencement à chaud (Hotlinking) d'images</a></h2>
<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
de votre site est <code>www.example.com</code>.</p>
<div class="example"><pre>
RewriteCond %{HTTP_REFERER} <strong>!^$</strong>
RewriteCond %{HTTP_REFERER} !www.example.com [NC]
RewriteRule <strong>\.(gif|jpg|png)$</strong> - [F,NC]
</pre></div>
<p>Dans le second exemple, plutôt que de rejeter la requête,
nous affichons une autre image à la place.</p>
<div class="example"><pre>
RewriteCond %{HTTP_REFERER} <strong>!^$</strong>
RewriteCond %{HTTP_REFERER} !www.example.com [NC]
RewriteRule <strong>\.(gif|jpg|png)$</strong> /images/go-away.png [R,NC]
</pre></div>
<p>Dans le troisième exemple, nous redirigeons la requête vers
une image appartenant à un site tiers.</p>
<div class="example"><pre>
RewriteCond %{HTTP_REFERER} <strong>!^$</strong>
RewriteCond %{HTTP_REFERER} !www.example.com [NC]
RewriteRule <strong>\.(gif|jpg|png)$</strong> http://other.site.com/image.gif [R,NC]
</pre></div>
<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>
</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 à 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
<code class="module"><a href="/mod/mod_rewrite.html">mod_rewrite</a></code> se situe en dessous (!) de
<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 alors utiliser la règle suivante pour une interdiction
concernant un hôte...</p>
<div class="example"><pre>
RewriteCond %{REMOTE_HOST} <strong>^mauvais-hôte\.mon-domaine\.com$</strong>
RewriteRule !^http://[^/.]\.mon-domaine.com.* - [F]
</pre></div>
<p>...et celle-ci pour une interdiction concernant un
utilisateur d'un certain hôte :</p>
<div class="example"><pre>
RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST}
<strong>^mauvais-sujet@mauvais-hôte\.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="external-rewriting" id="external-rewriting">Moteur de réécriture externe</a></h2>
<dl>
<dt>Description :</dt>
<dd>
<p>Une question de la Faq : comment résoudre le problème
FOO/BAR/QUUX/etc. ? <code class="module"><a href="/mod/mod_rewrite.html">mod_rewrite</a></code> ne semble pas
devoir y apporter de solution...</p>
</dd>
<dt>Solution :</dt>
<dd>
<p>Utiliser une <code class="directive"><a href="/mod/mod_rewrite.html#rewritemap">RewriteMap</a></code> ou table de réécriture externe, c'est
à dire un programme qui agit de la même façon qu'une
<code class="directive"><a href="/mod/mod_rewrite.html#rewritemap">RewriteMap</a></code>. 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>
<div class="example"><pre>
RewriteEngine on
RewriteMap quux-table <strong>prg:</strong>/chemin/vers/table.quux.pl
RewriteRule ^/~quux/(.*)$ /~quux/<strong>${quux-table:$1}</strong>
</pre></div>
<div class="example"><pre>
#!/chemin/vers/perl
# désactive la mise en tampon des entrées/sorties, qui risque
# 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 (&lt;&gt;) {
s|^foo/|bar/|;
print $_;
}
</pre></div>
<p>Ceci n'est qu'un exemple de démonstration qui ne fait que
réécrire les URLs du style <code>/~quux/foo/...</code> vers
<code>/~quux/bar/...</code>. En fait, vous pouvez programmer
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>
</div></div>
<div class="bottomlang">
<p><span>Langues Disponibles: </span></p>
</div><div id="footer">
<p class="apache">Copyright 2010 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>
View Git Blame Copy Permalink