Serveur Apache HTTP Version 2.4
Description: | Ce module fournit un moteur de réécriture à base de règles permettant de réécrire les URLs des requêtes à la volée |
---|---|
Statut: | Extension |
Identificateur de Module: | rewrite_module |
Fichier Source: | mod_rewrite.c |
Le module mod_rewrite
utilise un moteur de
réécriture à base de règles, basé sur un interpréteur
d'expressions rationnelles PCRE, pour réécrire les URLs à la volée. Par
défaut, mod_rewrite
met en correspondance une URL
avec le système de fichiers. Cependant, on peut aussi l'utiliser
pour rediriger une URL vers une autre URL, ou pour invoquer une
requête interne à destination du mandataire.
mod_rewrite
fournit une méthode souple et
puissante pour manipuler les URLs en utilisant un nombre illimité
de règles. Chaque règle peut être associée à un nombre illimité de
conditions, afin de vous permettre de réécrire les URLs en
fonction de variables du serveur, de variables d'environnement,
d'en-têtes HTTP, ou de repères temporels.
mod_rewrite
agit sur la totalité de l'URL, y
compris la partie chemin. Une règle de réécriture peut être
invoquée dans httpd.conf
ou dans un fichier
.htaccess
. Le chemin généré par une règle de
réécriture peut inclure une chaîne de paramètres, ou peut renvoyer
vers un traitement secondaire interne, une redirection vers une
requête externe ou vers le mandataire interne.
Vous trouverez d'avantage de détails, discussions et exemples dans la documentation détaillée sur mod_rewrite.
mod_rewrite
offre une journalisation détaillée
de ses actions aux niveaux de journalisation trace1
à
trace8
. Le niveau de journalisation peut être défini de
manière spécifique à mod_rewrite
via la directive
LogLevel
: jusqu'au niveau
debug
aucune action n'est journalisée, alors qu'elles
le sont pratiquement toutes au niveau trace8
.
mod_rewrite
va ralentir votre serveur HTTP Apache
de manière dramatique ! N'utilisez un niveau de journalisation
supérieur à trace2
qu'à des fins de débogage !
LogLevel alert rewrite:trace3
Ceux qui sont familiers avec les versions précédentes de
mod_rewrite
vont probablement rechercher en vain les
directives RewriteLog
et
RewriteLogLevel
. Elles ont été en effet remplacées
par une configuration de la journalisation par module, comme
mentionné plus haut.
Pour extraire les traces spécifiques à
mod_rewrite
, affichez le fichier journal en
redirigeant la sortie vers grep :
tail -f error_log|fgrep '[rewrite:'
Description: | Définit l'URL de base pour les réécritures au niveau répertoire |
---|---|
Syntaxe: | RewriteBase chemin URL |
Défaut: | Pas de valeur par défaut |
Contexte: | répertoire, .htaccess |
AllowOverride: | FileInfo |
Statut: | Extension |
Module: | mod_rewrite |
La directive RewriteBase
permet de
spécifier le préfixe d'URL à utiliser dans un contexte de
répertoire (htaccess) pour les directives
RewriteRule
qui réécrivent vers un chemin
relatif.
Cette directive est obligatoire si vous utilisez un chemin relatif dans une substitution, et dans un contexte de répertoire (htaccess), sauf si au moins une de ces conditions est vérifiée :
DocumentRoot
(c'est à
dire que pour y accéder, il n'est pas nécessaire d'utiliser
une directive telle qu'Alias
).RewriteRule
, suffixé par
la substitution relative est aussi valide en tant qu'URL sur
le serveur (ce qui est rare).Dans l'exemple ci-dessous, la directive
RewriteBase
est nécessaire afin d'éviter une
réécriture en http://example.com/opt/myapp-1.2.3/welcome.html car la
ressource n'était pas relative à la racine des documents. Cette erreur
de configuration aurait conduit le serveur à rechercher un répertoire
"opt" à la racine des documents.
DocumentRoot /var/www/example.com Alias /myapp /opt/myapp-1.2.3 <Directory /opt/myapp-1.2.3> RewriteEngine On RewriteBase /myapp/ RewriteRule ^index\.html$ welcome.html </Directory>
Description: | Définit une condition qui devra être satisfaite pour que la réécriture soit effectuée |
---|---|
Syntaxe: | RewriteCond
chaîne de test expression de comparaison |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | FileInfo |
Statut: | Extension |
Module: | mod_rewrite |
La directive RewriteCond
permet de définir une
condition d'exécution d'une règle. Une ou plusieurs conditions
RewriteCond
peuvent précéder une
directive RewriteRule
. La règle de réécriture correspondante n'est
ainsi exécutée que si ces conditions sont satisfaites,
et si l'URI correspond au modèle spécifié dans la
règle.
TestString est une chaîne qui peut contenir les extensions suivantes en plus du texte simple :
$N
(0 <= N <= 9). $1 à $9
permettent d'accéder aux parties regroupées (entre
parenthèses) du modèle, issues de la RewriteRule
concernée par le jeu de conditions RewriteCond
courant. $0 donne accès à l'ensemble de la chaîne
correspondant au modèle.%N
(0 <= N <= 9). %1 à %9
permettent d'accéder aux parties regroupées (entre
parenthèses) du modèle, issues de la RewriteRule
concernée par le jeu de conditions RewriteCond
courant. %0 donne accès à l'ensemble de la chaîne
correspondant au modèle.${nomTable:clé|défaut}
. Voir la href="#mapfunc">documentation sur RewriteMap
pour plus de détails.
%{
NAME_OF_VARIABLE }
,
où NOM_DE_VARIABLE peut contenir une chaîne issue
de la liste suivante :
En-têtes HTTP : | connexion & requête: | |
---|---|---|
HTTP_USER_AGENT HTTP_REFERER HTTP_COOKIE HTTP_FORWARDED HTTP_HOST HTTP_PROXY_CONNECTION HTTP_ACCEPT |
REMOTE_ADDR REMOTE_HOST REMOTE_PORT REMOTE_USER REMOTE_IDENT REQUEST_METHOD SCRIPT_FILENAME PATH_INFO QUERY_STRING AUTH_TYPE |
|
variables internes au serveur : | date et heure : | spéciaux : |
DOCUMENT_ROOT SERVER_ADMIN SERVER_NAME SERVER_ADDR SERVER_PORT SERVER_PROTOCOL SERVER_SOFTWARE |
TIME_YEAR TIME_MON TIME_DAY TIME_HOUR TIME_MIN TIME_SEC TIME_WDAY TIME |
API_VERSION THE_REQUEST REQUEST_URI REQUEST_FILENAME IS_SUBREQ HTTPS REQUEST_SCHEME |
Ces variables correspondent toutes aux en-têtes MIME
HTTP de mêmes noms, au variables C du serveur HTTP Apache, ou
aux champs struct tm
du système Unix. La
plupart d'entre elles sont documentées ailleurs dans le
manuel ou dans la spécification CGI.
SERVER_NAME et SERVER_PORT dépendent respectivement
des valeurs des directives UseCanonicalName
et UseCanonicalPhysicalPort
.
Parmi les variables spécifiques à mod_rewrite, ou trouve les suivantes :
IS_SUBREQ
API_VERSION
THE_REQUEST
GET
/index.html HTTP/1.1
"), à l'exclusion de tout
en-tête ajouté par le navigateur. Cette
valeur n'a pas été déséchappée (décodée), à la
différence de la plupart des variables suivantes.REQUEST_URI
QUERY_STRING
.REQUEST_FILENAME
REQUEST_FILENAME
contient la
valeur de REQUEST_URI
.HTTPS
mod_ssl
soit chargé ou non.REQUEST_SCHEME
ServerName
.Si la chaîne de test contient la valeur spéciale
expr
, expression de comparaison sera traité
en tant qu'expression rationnelle de type ap_expr.
Autres points à connaître ::
Les variables SCRIPT_FILENAME
et
REQUEST_FILENAME
contiennent toutes deux la valeur
du champ filename
de la
structure interne request_rec
du serveur HTTP Apache.
Le premier nom correspond au nom de variable bien connu CGI,
alors que le second est l'équivalent de REQUEST_URI (qui
contient la valeur du champ uri
de
request_rec
).
Si une substitution intervient et si la réécriture se poursuit, la valeur des deux variables sera mise à jour en conséquence.
Dans le contexte du serveur principal (c'est à dire avant que
la requête ne soit mise en correspondance avec le système de
fichiers), SCRIPT_FILENAME et REQUEST_FILENAME ne peuvent pas
contenir le chemin entier dans le système de fichiers local car
ce chemin b'est pas connu à ce stade du traitement. Dans ce cas,
les deux variables contiendront la valeur de REQUEST_URI. Pour
obtenir le chemin complet de la requête dans le système de
fichiers local dans le contexte du serveur principal, utilisez une
référence avant à base d'URL
%{LA-U:REQUEST_FILENAME}
pour déterminer la valeur
finale de REQUEST_FILENAME.
%{ENV:variable}
, où variable peut
correspondre à une variable d'environnement quelconque.%{ENV:variable}
est aussi disponible, où
variable peut correspondre à toute variable
d'environnement. Peut être consulté via des structures internes
d'Apache httpd et (si on ne les trouve pas ici) via la fonction
getenv()
à partir du processus du serveur Apache
httpd.mod_ssl
soit chargé ou non, on peut
utiliser %{SSL:variable}
, où variable
peut être remplacé par le nom d'une
variable
d'environnement SSL . Si mod_ssl
n'est pas
chargé, cette variable contiendra toujours une chaîne vide.
Exemple : %{SSL:SSL_CIPHER_USEKEYSIZE}
pourra
contenir la valeur 128
.%{HTTP:en-tête}
, où
en-tête peut correspondre à tout nom d'en-tête MIME
HTTP, pour extraire la valeur d'un en-tête envoyé dans la
requête HTTP. Par exemple, %{HTTP:Proxy-Connection}
contiendra la valeur de l'en-tête HTTP
"Proxy-Connection:
".
Si on utilise un en-tête HTTP
dans une condition, et si cette condition est évaluée à
vrai
pour la requête, cet en-tête sera ajouté à l'en-tête Vary de
la réponse. Il ne le sera pas si la condition est évaluée à
faux
. L'ajout de l'en-tête HTTP à l'en-tête Vary
est nécessaire à une mise en cache appropriée.
Il faut garder à l'esprit que les conditions suivent une
logique de cout-circuit si le drapeau
'ornext|OR
' est utilisé, et que de
ce fait, certaines d'entre elles ne seront pas évaluées.
%{LA-U:variable}
, qui
permet d'effectuer une sous-requête interne à base d'URL, afin
de déterminer la valeur finale de variable. Ceci permet
d'accéder à la valeur d'une variable pour la réécriture inconnue
à ce stade du traitement, mais qui sera définie au
cours d'une phase ultérieure.
Par exemple, pour effectuer une réécriture dépendant de la
variable REMOTE_USER
dans le contexte du serveur
principal (fichier httpd.conf
), vous devez utiliser
%{LA-U:REMOTE_USER}
- cette variable est définie
par la phase d'autorisation qui intervient après la
phase de traduction d'URL (pendant laquelle mod_rewrite opère).
Par contre, comme mod_rewrite implémente son contexte de
répertoire (fichier .htaccess
) via la phase Fixup
de l'API, et comme la phase d'autorisation intervient
avant cette dernière, vous pouvez vous contenter
d'utiliser %{REMOTE_USER}
dans ce contexte.
%{LA-F:variable}
peut être utilisée pour effectuer
une sous-requête interne (basée sur le nom de fichier), afin de
déterminer la valeur finale de variable. La plupart du
temps, elle est identique à LA-U (voir ci-dessus).expression de comparaison est une expression rationnelle qui est appliquée à l'instance actuelle de chaîne de test. chaîne de test est d'abord évaluée, puis comparée à l'expression de comparaison.
expression de comparaison est en général une expression rationnelle compatible perl, mais vous disposez des syntaxes supplémentaires suivantes pour effectuer d'autres tests utiles sur chaîne de test :
!
' (point d'exclamation) pour indiquer une
expression de non-correspondance.""
(deux guillemets),
chaîne de test est comparée à la chaîne vide.Si la chaîne de test contient la valeur spéciale
expr
, la chaîne de comparaison sera
traitée en tant qu'expression rationnelle de type ap_expr.
Dans l'exemple ci-dessous, on utilise -strmatch
pour comparer le REFERER
avec le nom d'hôte du
site afin de bloquer le hotlinking (référencement direct)
non désiré.
RewriteCond expr "! %{HTTP_REFERER} -strmatch '*://%{HTTP_HOST}/*'"
RewriteRule ^/images - [F]
[
drapeaux]
comme troisième argument de la directive
RewriteCond
, où drapeaux est un
sous-ensemble séparé par des virgules des drapeaux suivants :
nocase|NC
'
(no case)ornext|OR
'
(ou condition suivante)RewriteCond %{REMOTE_HOST} ^host1 [OR] RewriteCond %{REMOTE_HOST} ^host2 [OR] RewriteCond %{REMOTE_HOST} ^host3 RewriteRule ...règles concernant tous ces hôtes...Sans ce drapeau, les paires condition/règle devraient être écrites trois fois.
novary|NV
'
(no vary)Exemple :
Pour réécrire la page d'accueil d'un site en fonction de
l'en-tête ``User-Agent:
'' de la requête, vous
pouvez utiliser ce qui suit :
RewriteCond %{HTTP_USER_AGENT} ^Mozilla RewriteRule ^/$ /homepage.max.html [L] RewriteCond %{HTTP_USER_AGENT} ^Lynx RewriteRule ^/$ /homepage.min.html [L] RewriteRule ^/$ /homepage.std.html [L]
Explications : si vous utilisez un navigateur (Netscape Navigator, Mozilla etc) qui s'identifie comme 'Mozilla', vous accèderez à la page d'accueil max (qui peut contenir des frames, ou d'autres ressources particulières). Si vous utilisez le navigateur Lynx (qui est un navigateur en mode texte), vous accèderez à une page d'accueil min (qui peut être une version conçue pour une navigation simple basée sur le texte). Si aucune de ces conditions n'est satisfaite (vous utilisez tout autre navigateur, ou votre navigateur s'identifie de manière non standard), vous accèderez à la page d'accueil std (standard).
Description: | Active ou désactive l'exécution du moteur de réécriture |
---|---|
Syntaxe: | RewriteEngine on|off |
Défaut: | RewriteEngine off |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | FileInfo |
Statut: | Extension |
Module: | mod_rewrite |
La directive RewriteEngine
active ou
désactive l'exécution du moteur de réécriture. Si sa valeur est
off
, ce module n'exécutera aucun traitement et ne
mettra pas à jour les variables d'environnement
SCRIPT_URx
.
Pour désactiver le module, il vaut mieux utiliser cette
directive que commenter toutes les directives RewriteRule
!
Notez que les hôtes virtuels n'héritent pas des
configurations de réécriture. Ceci implique que vous devez
insérer une directive RewriteEngine on
dans chaque
hôte virtuel pour lequel vous souhaitez utiliser des règles
de réécriture.
Les directives RewriteMap
du type
prg
ne sont pas prises en compte au cours de
l'initialisation du serveur si elle ont été définies dans un
contexte où la directive RewriteEngine
n'a
pas été définie à on
.
Description: | Définit une fonction de mise en correspondance pour la recherche de mots-clés |
---|---|
Syntaxe: | RewriteMap nom de la correspondance type de
correspondance:source de la correspondance
|
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_rewrite |
Compatibilité: | Il est possible de choisir entre plusieurs types de bases de données depuis la version 2.0.41 du serveur HTTP Apache |
La directive RewriteMap
définit une
Table de correspondance pour la réécriture que les
fonctions de mise en correspondance
peuvent utiliser dans les chaînes de substitution des règles
pour insérer/substituer des champs en recherchant des mots-clés.
La source utilisée pour cette recherche peut être de plusieurs
types.
nom de la correspondance est le nom de la table de correspondance et servira à spécifier une fonction de mise en correspondance pour les chaînes de substitution d'une règle de réécriture selon une des constructions suivantes :
${
nom de la
correspondance :
mot-clé }
${
nom de la
correspondance :
mot-clé |
valeur par défaut
}
Lorsqu'une telle construction est rencontrée, la table de correspondance Nom de la correspondance est consultée et la clé mot-clé recherchée. Si la clé est trouvée, la construction est remplacée par la valeur de remplacement. Si la clé n'est pas trouvée, elle est remplacée par la valeur par défaut, ou par une chaîne vide si aucune valeur par défaut n'est spécifiée. La valeur vide se comporte comme si la clé était absente ; il est donc impossible de distinguer une valeur vide d'une absence de clé.
Par exemple, vous pouvez définir une directive
RewriteMap
comme suit
RewriteMap map-exemple txt:/chemin/vers/fichier/map.txt
Vous pourrez ensuite utiliser cette table dans une
directive RewriteRule
comme suit :
RewriteRule ^/ex/(.*) ${map-exemple:$1}
Les combinaisons suivantes pour type de correspondance et source de la correspondance peuvent être utilisées :
httxt2dbm
(Détails ...).RewriteMap
: toupper, tolower, escape ou unescape
(Détails ...).Vous trouverez plus de détails et de nombreux exemples dans le RewriteMap HowTo.
Description: | Configure certaines options spéciales pour le moteur de réécriture |
---|---|
Syntaxe: | RewriteOptions Options |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | FileInfo |
Statut: | Extension |
Module: | mod_rewrite |
Compatibilité: | MaxRedirects n'est plus disponible depuis
la version version 2.1 |
La directive RewriteOptions
définit
certaines options spéciales pour la configuration au niveau du
serveur ou du répertoire. La chaîne de caractères Option
ne peut actuellement prendre qu'une des valeurs suivantes :
Inherit
Ceci force la configuration locale à hériter de la
configuration du niveau supérieur. Dans le contexte des hôtes
virtuels, cela signifie que les correspondances, conditions et
règles du serveur principal sont héritées. Dans le contexte des
répertoires, cela signifie que les conditions et règles de la
configuration .htaccess
ou les sections <Directory>
du répertoire
parent sont héritées. Les règles héritées sont virtuellement
copiées dans la section où cette directive est utilisée. Si elles
sont utilisées avec des règles locales, les règles héritées sont
placées après ces dernières. La place de cette directive - avant
ou après les règles locales - n'a aucune influence sur ce
comportement. Si des règles locales ont forcé l'arrêt de la
réécriture, les règles héritées ne seront pas traitées.
InheritBefore
Même effet que l'option Inherit
ci-dessus, mais
les règles spécifiées dans le niveau parent s'appliquent
avant les règles spécifiées dans le niveau
enfant. Disponible depuis la version 2.3.10 du serveur HTTP
Apache.
AllowNoSlash
Par défaut, mod_rewrite
ignore les URLs qui
correspondent à un répertoire sur disque, mais ne comportent pas
de slash final, afin que le module mod_dir
redirige le client vers l'URL canonique avec un slash final.
Lorsque la directive DirectorySlash
est définie à off, il
est possible de spécifier l'option AllowNoSlash
pour
s'assurer que les règles de réécriture ne soient plus ignorées.
Si on le souhaite, cette option permet de faire s'appliquer des
règles de réécriture qui correspondent à un répertoire sans slash
final au sein de fichiers .htaccess. Elle est disponible à
partir de la version 2.4.0 du serveur HTTP Apache.
AllowAnyURI
A partir de la version 2.2.22 de httpd, lorsqu'une directive RewriteRule
se situe dans un
contexte de serveur virtuel
ou de serveur principal,
mod_rewrite
ne traitera les règles de réécriture
que si l'URI de la requête respecte la syntaxe d'un chemin URL. Ceci permet
d'éviter certains problèmes de sécurité où des règles
particulières pourraient permettre des développements de modèles
inattendus (voir CVE-2011-3368
et CVE-2011-4317).
Pour s'affranchir de la restriction relative à la syntaxe des chemins URL, on peut
utiliser l'option AllowAnyURI
, afin de permettre à
mod_rewrite
d'appliquer le jeu de règles à toute
chaîne de requête URI, sans vérifier si cette dernière respecte la
grammaire des chemins URL définie dans la spécification HTTP.
L'utilisation de cette option rendra le serveur vulnérable à
certains problèmes de sécurité si les règles de réécritures
concernées n'ont pas été rédigées avec soin. Il est par conséquent
fortement recommandé de ne pas utiliser cette
option. En particulier, prêtez attention aux chaînes en entrée contenant le
caractère '@
', qui peuvent modifier l'interprétation
de l'URI réécrite, comme indiqué dans les liens ci-dessus.
Description: | Définit les règles pour le moteur de réécriture |
---|---|
Syntaxe: | RewriteRule
Modèle Substitution [drapeaux] |
Contexte: | configuration du serveur, serveur virtuel, répertoire, .htaccess |
AllowOverride: | FileInfo |
Statut: | Extension |
Module: | mod_rewrite |
La directive RewriteRule
est le
véritable cheval de trait de la réécriture. La directive peut
apparaître plusieurs fois, chaque instance définissant une
règle de réécriture particulière. L'ordre dans lequel ces règles
sont définies est important - il s'agit de l'ordre dans lequel
les règles seront appliquées au cours du processus de
réécriture.
Modèle est une expression rationnelle compatible perl. Dans la première règle de réécriture, l'expression est comparée au (%-decoded) chemin de l'URL (ou au chemin fichier, en fonction du contexte) de la requête. Les expressions suivantes sont comparées à la sortie de la dernière règle de réécriture qui correspondait.
Dans un contexte de serveur virtuel VirtualHost
, le modèle est tout
d'abord comparé à la portion de l'URL située entre le nom d'hôte
éventuellement accompagné du port, et la chaîne de paramètres (par
exemple "/app1/index.html").
Dans les contextes de répertoire Directory
et htaccess, le
modèle est tout d'abord comparé au chemin du système
de fichiers, après suppression du préfixe ou chemin de base
ayant conduit le serveur vers la règle RewriteRule
(par
exemple "app1/index.html" ou
"index.html" selon l'endroit où les directives sont définies).
Si vous souhaitez faire une comparaison sur le nom
d'hôte, le port, ou la chaîne de requête, utilisez une
directive RewriteCond
comportant respectivement les variables
%{HTTP_HOST}
, %{SERVER_PORT}
, ou
%{QUERY_STRING}
.
<Directory>
est un peu plus
complexe.RewriteEngine On
" et
"Options FollowSymLinks
". Si l'administrateur a désactivé
la possibilité de modifier l'option FollowSymLinks
au
niveau du répertoire d'un utilisateur, vous ne pouvez pas utiliser le
moteur de réécriture. Cette restriction a été instaurée à des fins de
sécurité..htaccess
, le chemin de base du répertoire courant (qui est
toujours le même pour ce même répertoire) est automatiquement
supprimé au cours de la comparaison avec le modèle de la règle
de réécriture, et automatiquement ajouté lorsqu'une
substitution relative (ne débutant pas par un slash ou un nom de
protocole) arrive à la fin d'un jeu de règles. Voir la directive
RewriteBase
pour plus de
détails à propos de l'ajout du préfixe après les substitutions
relatives.%{REQUEST_URI}
dans la directive
RewriteCond
.^/
ne correspondra jamais dans un contexte de répertoire.<Location>
et <Files>
, elles n'y sont pas prises en compte, et
n'y sont à priori d'aucune utilité.Pour quelques conseils à propos des expressions rationnelles, voir le document Introduction à mod_rewrite.
Dans mod_rewrite, on peut aussi utiliser le caractère NON
('!
') comme préfixe de modèle. Ceci vous permet
d'inverser la signification d'un modèle, soit pour dire
``si l'URL considérée ne correspond PAS à
ce modèle''. Le caractère NON peut donc être utilisé à
titre exceptionnel, lorsqu'il est plus simple d'effectuer une
comparaison avec le modèle inversé, ou dans la dernière règle
par défaut.
$N
dans la chaîne de
substitution !
Dans une règle de réécriture, Substitution est la chaîne de caractères qui remplace le chemin de l'URL original qui correspondait au Modèle. Substitution peut être :
DocumentRoot
vers la ressource qui
doit être servie. Notez que mod_rewrite
essaie de deviner si vous avez spécifié un chemin du système
de fichiers ou un chemin d'URL en vérifiant si la première
partie du chemin existe à la racine du système de fichiers.
Par exemple, si vous avez spécifié comme chaîne de
Substitution /www/file.html
, cette
dernière sera traitée comme un chemin d'URL à moins
qu'un répertoire nommé www
n'existe à la racine
de votre système de fichiers, auquel cas la chaîne de
substitution sera traitée comme un chemin du système de
fichiers. Si vous désirez que d'autres directives de
correspondance d'URL (comme la directive Alias
) soient appliquées au
chemin d'URL résultant, utilisez le drapeau [PT]
comme décrit ci-dessous.mod_rewrite
vérifie si le nom d'hôte
correspond à celui de l'hôte local. Si c'est le cas, le
protocole et le nom d'hôte sont supprimés, et ce qui reste est
traité comme un chemin d'URL. Dans le cas contraire, une
redirection externe vers l'URL indiquée est effectuée. Pour
forcer une redirection externe vers l'hôte local, voir le
drapeau [R]
ci-dessous.-
(tiret)En plus du texte, la chaîne Substition peut comporter :
$N
) vers le modèle
d'une directive RewriteRule%N
) vers le dernier
modèle d'une directive RewriteCond qui correspondait%{VARNAME}
)${nom correspondance:clé|défaut}
)Les références arrières sont des identificateurs de la forme
$
N (N=0..9), qui
seront remplacés par le contenu du Nème groupe
du Modèle qui correspondait. Les variables du serveur
sont les mêmes que dans la Chaîne de test d'une
directive RewriteCond
. Les fonctions de comparaison
sont issues de la directive RewriteMap
dans la
section de laquelle elles sont décrites. Ces trois types de
variables sont évaluées dans l'ordre ci-dessus.
Chaque règle de réécriture s'applique au résultat de la règle
précédente, selon l'ordre dans lequel elles ont été définies dans
le fichier de configuration. Le chemin de l'URL ou du système de fichier (voir
ci-dessus Qu'est-ce qui est
comparé ?) est intégralement
remplacée par la chaîne de Substitution et le
processus de réécriture se poursuit jusqu'à ce que toutes les
règles aient été appliquées, ou qu'il soit explicitement stoppé
par un drapeau L
,
ou par un autre drapeau qui implique un arrêt immédiat, comme
END
ou
F
.
Par défaut, la chaîne de requête est transmise sans
modification. Vous pouvez cependant créer dans la chaîne de
substitution des URLs dont une partie constitue une chaîne de
requête. Pour cela, ajoutez simplement un point d'interrogation
dans la chaîne de substitution pour indiquer que le texte qui
suit doit être réinjecté dans la chaîne de requête. Pour
supprimer une chaîne de requête, terminez simplement la chaîne de
substitution par un point d'interrogation. Pour combiner les
nouvelles chaînes de requête avec les anciennes, utilisez le
drapeau [QSA]
.
En outre, vous pouvez spécifier des actions spéciales à effectuer en ajoutant
des
[
drapeaux]
comme troisième argument de la directive
RewriteRule
. Séparés par des virgules au sein d'une
liste encadrée par des crochets, les drapeaux peuvent
être choisis dans la table suivante. Vous trouverez plus de
détails, et des exemples pour chaque drapeau dans le document à propos des drapeaux de
réécriture.
Drapeaux et syntaxe | Fonction |
---|---|
B | Echappe les caractères non-alphanumériques avant d'appliquer la transformation. détails ... |
chain|C | La règle est chaînée avec la règle suivante. Si la règle échoue, la ou les règles avec lesquelles elle est est chaînée seront sautées. détails ... |
cookie|CO=NAME:VAL | Définit un cookie au niveau du navigateur client. La syntaxe complète est : CO=NAME:VAL:domain[:lifetime[:path[:secure[:httponly]]]] details ... détails ... |
discardpath|DPI | Supprime la partie PATH_INFO de l'URI réécrit. détails ... |
env|E=[!]VAR[:VAL] | Définit la variable d'environnement VAR (à la valeur VAL si elle est fournie). La variante !VAR annule la définition de la variable VAR.détails ... |
forbidden|F | Renvoie une réponse 403 FORBIDDEN au navigateur client. détails ... |
gone|G | Renvoie un message d'erreur 410 GONE au navigateur client. détails ... |
Handler|H=Gestionnaire de contenu | L'URI résultant est envoyé au Gestionnaire de contenu pour traitement. détails ... |
last|L | Arrête le processus de réécriture immédiatement et n'applique plus aucune règle. Prêtez une attention particulière aux mises en garde concernant les contextes de niveau répertoire et .htaccess (voir aussi le drapeau END). détails ... |
next|N | Réexécute le processus de réécriture à partir de la première règle, en utilisant le résultat du jeu de règles, sous réserve qu'il y ait un point de départ. détails ... |
nocase|NC | Rend la comparaison entre modèles insensible à la casse. détails ... |
noescape|NE | Empêche mod_rewrite d'effectuer un échappement hexadécimal des caractères spéciaux dans le résultat de la réécriture. détails ... |
nosubreq|NS | La règle est sautée si la requête courante est une sous-requête interne. détails ... |
proxy|P | Force l'envoi en interne de l'URL de substitution en tant que requête mandataire. détails ... |
passthrough|PT | L'URI résultant est repassé au moteur de mise en
correspondance des URLs pour y être traité par d'autres
traducteurs URI-vers-nom de fichier, comme Alias ou
Redirect . détails ... |
qsappend|QSA | Ajoute toute chaîne de paramètres présente dans l'URL de la requête originale à toute chaîne de paramètres créée dans la cible de réécriture. détails ... |
qsdiscard|QSD | Supprime toute chaîne de paramètres de l'URI entrant. détails ... |
redirect|R[=code] | Force une redirection externe, avec un code de statut HTTP optionnel. détails ... |
END | Arrête le processus de réécriture immédiatement et n'applique plus aucune règle. Empêche aussi l'exécution ultérieure de règles de réécriture dans des contextes de répertoire et des fichiers .htaccess (disponible depuis la version 2.3.9) détails ... |
skip|S=nombre | Si la règle courante s'applique, le moteur de réécriture doit sauter les nombre règles suivantes. détails ... |
type|T=MIME-type | Force l'attribution du Type-MIME spécifié au fichier cible. détails ... |
Quand la chaîne de substitution commence par quelque chose comme
"/~user" (de manière explicite ou par références arrières), mod_rewrite
développe le répertoire home sans tenir compte de la présence ou de la
configuration du module mod_userdir
.
Ce développement n'est pas effectué si le drapeau PT est
utilisé dans la directive RewriteRule
Voici toutes les combinaisons de substitution et leurs significations :
Dans la configuration au niveau du serveur principal
(httpd.conf
)
pour la requête ``GET
/chemin/infochemin
'':
Règle | Résultat de la substitution |
---|---|
^/un_chemin(.*) autre_chemin$1 | invalide, non supporté |
^/un_chemin(.*) autre_chemin$1 [R] | invalide, non supporté |
^/un_chemin(.*) autre_chemin$1 [P] | invalide, non supporté |
^/un_chemin(.*) /autre_chemin$1 | /autre_chemin/info_chemin |
^/un_chemin(.*) /autre_chemin$1 [R] | http://cet_hote/autre_chemin/info_chemin via une redirection externe |
^/un_chemin(.*) /autre_chemin$1 [P] | sans objet, non supporté |
^/un_chemin(.*) http://cet_hote/autre_chemin$1 | /autre_chemin/info_chemin |
^/un_chemin(.*) http://cet_hote/autre_chemin$1 [R] | http://cet_hote/autre_chemin/info_chemin via une redirection externe |
^/un_chemin(.*) http://cet_hote/autre_chemin$1 [P] | sans objet, non supporté |
^/un_chemin(.*) http://autre_hote/autre_chemin$1 | http://autre_hote/autre_chemin/info_chemin via une redirection externe |
^/un_chemin(.*) http://autre_hote/autre_chemin$1 [R] | http://autre_hote/autre_chemin/info_chemin (le drapeau [R] est redondant) |
^/somepath(.*) http://otherhost/otherpath$1 [P] | http://otherhost/otherpath/pathinfo via internal proxy |
Dans une configuration de niveau répertoire pour
/chemin
(/chemin/physique/vers/chemin/.htacccess
, avec
RewriteBase /chemin
)
pour la requête ``GET
/chemin/chemin-local/infochemin
'':
Règle | Résultat de la substitution |
---|---|
^chemin-local(.*) autre-chemin$1 | /chemin/autre-chemin/infochemin |
^chemin-local(.*) autre-chemin$1 [R] | http://cet-hôte/chemin/autre-chemin/infochemin via redirection externe |
^chemin-local(.*) autre-chemin$1 [P] | n'a pas lieu d'être, non supporté |
^chemin-local(.*) /autre-chemin$1 | /autre-chemin/infochemin |
^chemin-local(.*) /autre-chemin$1 [R] | http://cet-hôte/autre-chemin/infochemin via redirection externe |
^chemin-local(.*) /autre-chemin$1 [P] | n'a pas lieu d'être, non supporté |
^chemin-local(.*) http://cet-hôte/autre-chemin$1 | /autre-chemin/infochemin |
^chemin-local(.*) http://cet-hôte/autre-chemin$1 [R] | http://cet-hôte/autre-chemin/infochemin via redirection externe |
^chemin-local(.*) http://cet-hôte/autre-chemin$1 [P] | n'a pas lieu d'être, non supporté |
^chemin-local(.*) http://autre hôte/autre-chemin$1 | http://autre hôte/autre-chemin/infochemin via redirection externe |
^chemin-local(.*) http://autre hôte/autre-chemin$1 [R] | http://autre hôte/autre-chemin/infochemin via redirection externe (le drapeau [R] est redondant) |
^chemin-local(.*) http://autre hôte/autre-chemin$1 [P] | http://autre hôte/autre-chemin/infochemin via un mandataire interne |