Ce document est un complément à la Documentation de référence de
Supposons que nous ayons récemment renommé la page
foo.html en bar.html, 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.
On réécrit l'ancienne URL en interne vers la nouvelle via la règle suivante :
Supposons toujours que nous ayons récemment renommé la page
foo.html en bar.html, et voulions
maintenant que l'ancienne URL soit toujours valide à des fins
de compatibilité ascendante. En revanche, nous voulons cette
fois que la nouvelle URL soit suggérée aux utilisateurs de
l'ancienne URL, c'est à dire que l'adresse vue depuis leur
navigateur doit également être modifiée.
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 :
Dans l'exemple interne, on a utilisé mod_rewrite afin de dissimuler la redirection au client. Dans cet exemple, en revanche, on aurait pu se contenter d'une directive Redirect :
Si une ressource a été déplacée vers un autre serveur, vous pouvez faire en sorte que les URLs de l'ancien serveur continuent de fonctionner pendant un certain temps, afin de laisser au utilisateurs le temps de modifier leurs favoris.
Vous pouvez utiliser
Comment transformer une page statique foo.html
en sa variante dynamique foo.cgi de manière
transparente, c'est à dire sans en avertir le
navigateur/utilisateur.
On réécrit simplement l'URL en script CGI et force le
gestionnaire de contenu à cgi-script de façon
à ce que le script s'exécute en tant que programme CGI.
Ainsi, une requête vers /~quux/foo.html conduit
en interne à l'invocation de
/~quux/foo.cgi.
Comment conférer une compatibilité ascendante aux URLs
(existant encore virtuellement) après avoir migré
document.YYYY vers document.XXXX,
c'est à dire après avoir par exemple traduit un lot de
fichiers .html en fichiers .php
?
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.
Cet exemple utilise une fonctionnalité souvent méconnue de
mod_rewrite, en tirant avantage de l'ordre d'exécution du jeu de
règles. En particulier, mod_rewrite évalue la partie gauche des
règles de réécriture avant d'évaluer les directives RewriteCond. En
conséquence, $1 est déjà défini au moment où les directives
RewriteCond sont évaluées. Ceci nous permet de tester l'existence du
fichier original (document.html) et du fichier cible
(document.php) en utilisant le même nom de base.
Ce jeu de règles est conçu pour une utilisation dans un contexte
de répertoire (au sein d'une section <Directory> ou d'un
fichier .htaccess), de façon à ce que les vérifications
-f effectuent leurs recherches dans le bon répertoire.
Vous serez peut-être amené à définir une directive
Pour y parvenir, il vaut mieux se passer de mod_rewrite, et utiliser
plutôt la directive
Vous pouvez aussi utiliser la directive
Ou, par exemple, pour rediriger une portion de votre site vers HTTPS :
Si, pour une raison particulière, vous voulez tout de même utiliser
mod_rewrite - dans le cas, par exemple, où vous avez besoin
d'un jeu plus important de règles de réécritures - vous pouvez utiliser
la recette suivante :
Pour les sites écoutant sur un port autre que 80:
Et pour un site écoutant sur le port 80
Si vous souhaitez que cette règle s'applique à tous les noms de domaine - en d'autres termes, si vous voulez rediriger example.com vers www.example.com pour toutes les valeurs possibles de example.com, vous pouvez utiliser le jeu de règles suivants :
Vous pouvez utiliser ce jeu de règles aussi bien dans le fichier
de configuration de votre serveur principal que dans un fichier
.htaccess placé dans le répertoire défini par la
directive
Une ressource peut exister dans plusieurs répertoires, et nous voulons rechercher cette ressource dans ces répertoires lorsqu'elle fait l'objet d'une requête. Il est possible que nous ayons récemment réorganisé la structure de notre site en répartissant son contenu dans plusieurs répertoires.
Le jeu de règles suivant recherche la ressource dans deux répertoires, et s'il ne la trouve dans aucun des deux, il tentera simplement de la servir à partir de l'adresse fournie dans la requête.
Notre site web possède de nombreux miroirs, et nous voulons rediriger les utilisateurs vers celui qui se situe dans le pays où ils se trouvent.
En consultant le nom d'hôte du client demandeur, on détermine le pays dans lequel il se trouve. S'il est impossible d'effectuer une recherche sur leur adresse IP, on se rabat sur un serveur par défaut.
Nous allons utiliser une directive
on de la directive La directive
Sur certains serveurs, une ressource peut posséder plusieurs URLs. Il y a en général les URLs canoniques (celles qui sont réellement distribuées et utilisées), et celles qui correspondent à des raccourcis, les URLs internes, etc... Quelle que soit l'adresse que l'utilisateur fournit dans la requête, il devrait finalement voir l'URL canonique dans la barre d'adresse de son navigateur.
Nous effectuons une redirection HTTP externe pour toutes les
URLs non canoniques afin de les corriger dans la barre d'adresse
du navigateur, et ceci pour toutes les requêtes futures. Dans le
jeu de règles suivant, nous remplaçons /matous et
/minettes par le canonique /chats.
En général, le répertoire /". Ce répertoire ne contient cependant pas forcément des
ressources de première importance pour l'utilisateur. Par exemple, vous
préférerez peut-être que le répertoire d'accueil d'un visiteur accédant
pour la première fois à votre site soit un répertoire particulier
/a-propos-de/. Pour y parvenir, utilisez le jeu de règles
suivant :
On redirige l'URL / vers
/a-propos-de/ :
Notez que l'on peut aussi y parvenir en utilisant la directive
Notez aussi que cet exemple ne réécrit que l'URL racine. En d'autres
termes, il réécrit une requête pour http://example.com/,
mais pas pour une requête http://example.com/page.html. Si
vous avez effectivement modifié la racine de vos documents - c'est à dire
si tous vos contenus se trouvent dans un
sous-répertoire, il est largement préférable de modifier simplement
votre directive
Depuis la version 2.2.16, vous pouvez y parvenir via la directive
Cependant, si vos besoins étaient plus complexes, vous pouviez, dans les versions plus anciennes d'Apache, utiliser un jeu de règles du style :
D'autre part, si vous voulez transmettre l'URI de la requête en tant que chaîne de paramètres à index.php, vous pouvez remplacer cette règle de réécriture par :
Notez que l'on peut utiliser ces jeux de règles aussi bien dans un
fichier .htaccess que dans une section
<Directory>.
Dans la plupart des solutions de cette section, on utilise la même condition qui stocke la valeur recherchée dans la référence arrière %2. %1 est le début de la requête, et %3 ce qui reste. Cette condition est un peu complexe car elle introduit de la flexibilité et évite les doubles perluettes '&&' dans les substitutions.