Serveur Apache HTTP Version 2.2
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 |
Compatibilité: | Disponible à partir de la version 1.3 d'Apache |
Ce module utilise un moteur de réécriture à base de règles (basé sur un interpréteur d'expressions rationnelles) pour réécrire les URLs des requêtes à la volée. Il accepte un nombre illimité de règles, ainsi q'un nombre illimité de conditions attachées à chaque règle, fournissant ainsi un mécanisme de manipulation d'URL vraiment souple et puissant. Les manipulations d'URL peuvent dépendre de nombreux tests, des variables du serveur, des variables d'environnement, des en-têtes HTTP ou de l'horodatage. On peut même lancer des requêtes vers une base de données externe sous divers formats, afin d'obtenir une sélection d'URL très fine.
Ce module agit sur l'ensemble de l'URL (la partie concernant
le chemin incluse) au niveau du serveur
(apache2.conf
) mais aussi au niveau du répertoire
(.htaccess
), et peut générer des parties de chaîne
de requête comme résultat. Le résultat de la réécriture peut
renvoyer vers un sous-traitement interne, une redirection vers
une requête externe, ou même vers le flux d'un proxy interne.
Vous trouverez d'avantage de détails, discussions et exemples dans la documentation détaillée sur mod_rewrite.
Depuis Apache 1.3.20, les caractères spéciaux dans les
chaînes de test et les chaînes de Substitution
peuvent être échappés (c'est à dire traités comme des caractères
normaux sans tenir compte de leur signification en tant que
caractère spécial), en les faisant précéder d'un caractère
anti-slash ('\'). En d'autres termes, vous pouvez inclure un
véritable signe "dollar" dans une chaîne de Substitution
en utilisant '\$
' ; ceci empêche mod_rewrite de le
traiter comme une référence arrière.
Ce module conserve le contenu de deux variables d'environnement
CGI/SSI additionnelles (non standards) nommées
SCRIPT_URL
et SCRIPT_URI
. Celles-ci
contiennent l'adresse logique vue du Web
de la ressource concernée, tandis que les variables CGI/SSI
standards SCRIPT_NAME
et
SCRIPT_FILENAME
contiennent l'adresse
physique de la ressource vue du système.
Note : ces variables conservent l'URI/URL telle qu'elle était à l'arrivée de la requête, c'est à dire avant tout processus de réécriture. Il est important de le savoir car le processus de réécriture est principalement utilisé pour réécrire des URLs logiques en chemins physiques.
SCRIPT_NAME=/sw/lib/w3s/tree/global/u/rse/.www/index.html SCRIPT_FILENAME=/u/rse/.www/index.html SCRIPT_URL=/u/rse/ SCRIPT_URI=http://en1.engelschall.com/u/rse/
Par défaut, les hôtes virtuels n'héritent pas de la
configuration de mod_rewrite
telle qu'elle est
définie dans le contexte du serveur principal. Pour que la
configuration du serveur principal s'applique aux hôtes virtuels,
vous devez insérez les directives suivantes dans chaque section
<VirtualHost>
:
RewriteEngine On
RewriteOptions Inherit
Vous trouverez de nombreux exemples d'utilisation courante (et moins courante) de mod_rewrite dans la documentation spécifique à la réécriture.
Description: | Définit l'URL de base pour les réécritures au niveau répertoire |
---|---|
Syntaxe: | RewriteBase chemin URL |
Défaut: | Voir utilisation pour plus d'informations. |
Contexte: | répertoire, .htaccess |
AllowOverride: | FileInfo |
Statut: | Extension |
Module: | mod_rewrite |
La directive RewriteBase
définit
explicitement l'URL de base pour les réécritures au niveau du
répertoire. Comme vous le verrez plus loin, la directive
RewriteRule
peut
être utilisée dans les fichiers de configuration au niveau du
répertoire (.htaccess
). Elle agit alors localement,
en amputant le répertoire local de son préfixe avant traitement,
et en n'appliquant les règles de réécriture que sur ce qui reste
de l'URL. Lorsque le traitement est terminé, le préfixe est
automatiquement rajouté à l'URL. La valeur par défaut est
RewriteBase
chemin répertoire physique
Lorsqu'une substitution intervient pour une nouvelle URL, ce
module doit réinjecté l'URL dans le traitement du serveur. Pour
y parvenir, il doit connaître le préfixe de l'URL ou l'URL de
base correspondants. Par défaut, le préfixe est le chemin du
fichier correspondant lui-même. Cependant, pour la
plupart des sites web, les URLs ne correspondent PAS directement
aux chemins des fichiers physiques, cette assertion s'avère
ainsi souvent fausse !. C'est pourquoi vous pouvez
utiliser la directive RewriteBase
pour spécifier
le préfixe correct.
RewriteBase
dans chaque
fichier .htaccess
où vous voudrez utiliser des
directives RewriteRule
.
Par exemple, considérons le fichier de configuration de répertoire suivant :
# # /abc/def/.htaccess -- fichier de configuration pour le répertoire /abc/def # Rappel : /abc/def est le chemin physique de /xyz, # ce qui veut dire que la configuration du serveur comporte # une directive du style 'Alias /xyz /abc/def'. # RewriteEngine On # faisons savoir au serveur qu'on nous a atteint via /xyz et non par # le chemin physique /abc/def RewriteBase /xyz # maintenant les règles de réécriture RewriteRule ^avant\.html$ après.html
Dans l'exemple précédent, une requête pour
/xyz/avant.html
sera correctement réécrite sous
sous sa forme chemin physique
/abc/def/après.html
.
La liste suivante fournit des informations détaillées à propos des étapes du traitement interne :
Requête : /xyz/avant.html Traitement interne : /xyz/avant.html -> /abc/def/avant.html (Alias au niveau serveur) /abc/def/avant.html -> /abc/def/après.html (RewriteRule au niveau répertoire) /abc/def/après.html -> /xyz/après.html (RewriteBase au niveau répertoire) /xyz/après.html -> /abc/def/après.html (Alias au niveau serveur) Résultat : /abc/def/après.html
Tout ceci paraît très compliqué, mais correspond réellement au traitement interne d'Apache. Comme la réécriture au niveau du répertoire intervient plus tard au cours du traitement, la requête de réécriture doit être réinjectée dans le noyau d'Apache, comme s'il s'agissait d'une nouvelle requête (Voir les détails techniques à propos de mod_rewrite). La surcharge correspondante n'est pas aussi importante qu'il n'y paraît, car la réinjection est entièrement prise en charge en interne par Apache (comme c'est d'ailleurs le cas pour de nombreuses autres opérations effectuées à l'intérieur d'Apache).
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
définit une
condition d'application d'une certaine règle. Une ou plusieurs
directives RewriteCond
peuvent précéder
une directive
RewriteRule
. La règle
qui suit n'est appliquée que si l'état actuel de l'URI
correspond à son modèle, et si les conditions sont satisfaites.
chaîne de test est une chaîne de caractères qui peut contenir, en plus du plein texte, les constructions étendues suivantes :
$N
(0 <= N <= 9), qui
donnent accès aux parties groupées (entre parenthèses) du
modèle tiré de la RewriteRule
assujettie au
jeu de conditions concerné.
%N
(1 <= N <= 9), qui
donnent accès aux parties groupées (là aussi entre
parenthèses) du modèle de la dernière condition satisfaite
du jeu de conditions concerné.
${nomTable:clé|défaut}
. Voir
la documentation de
RewriteMap pour plus de détails.
%{
NOM_DE_VARIABLE
}
%{
NOM_DE_VARIABLE
}
où NOM_DE_VARIABLE
peut être une chaîne de caractères faisant partie 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 |
Toutes ces variables correspondent nom pour nom aux
en-têtes MIME HTTP, aux variables C du serveur Apache
ou aux champs struct tm
du système Unix.
La plupart sont documentées dans une autre partie du
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).Autres points à connaître :
Les variables SCRIPT_FILENAME et REQUEST_FILENAME ont la
même valeur - celle du champ filename
de la
structure interne du serveur Apache request_rec
.
Le premier nom est bien connu en tant que variable CGI,
alors que le second est équivalent à REQUEST_URI (qui contient
la valeur du champ uri
de la structure
request_rec
).
Si une substitution survient, et si la réécriture se poursuit, la valeur des deux variables est mise à jour en conséquence.
Dans un contexte de serveur principal (c'est à dire avant que
la requête n'ait été mise en relation avec le système de
fichiers), SCRIPT_FILENAME et REQUEST_FILENAME ne peuvent pas
contenir le chemin local entier dans le système de fichiers, car
celui-ci n'a pas encore été déterminé à ce stade du traitement.
Les deux variables contiennent alors la valeur de REQUEST_URI.
Pour obtenir le chemin local entier associé à la requête dans le
système de fichiers
dans un contexte de serveur principal, utilisez une recherche
avant %{LA-U:REQUEST_FILENAME}
pour déterminer la
valeur finale de REQUEST_FILENAME.
%{ENV:variable}
, où
variable peut être remplacé par toute variable
d'environnement. Ces variables sont recherchées dans les
structures internes d'Apache, et (si elles n'y figurent pas)
via getenv()
depuis le processus du serveur
Apache.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, mais la valeur produite sera toujours
une chaîne de caractères vide si mod_ssl
n'est
pas chargé. Exemple :
%{SSL:SSL_CIPHER_USEKEYSIZE}
peut correspondre
à 128
.%{HTTP:header}
,
où header peut être remplacé par tout nom d'en-tête
MIME HTTP. Exemple : %{HTTP:Proxy-Connection}
est
la valeur de l'en-tête HTTP ``Proxy-Connection:
''.
Si une condition contient un en-tête HTTP, il est ajouté à l'en-tête Vary de la réponse dans le cas où la condition est évaluée à true pour la requête. Dans le cas contraire, il n'est pas ajouté. L'ajout de l'en-tête HTTP à l'en-tête Vary de la réponse s'avère nécessaire pour une mise en cache correcte.
Il faut garder à l'esprit que les conditions suivent une
logique de court-circuit en cas de présence du drapeau
'ornext|OR
', si bien que
certaines d'entre elles sont susceptibles de ne pas être
évaluées du tout.
%{LA-U:variable}
pour les
recherches en avant qui effectuent une sous-requête interne
(basée sur l'URL), pour déterminer la valeur finale de
variable. Cela peut servir à accéder à une variable
(nécessaire pour une réécriture) qui n'est pas disponible dans
la situation présente, mais le sera dans une phase ultérieure.
Par exemple, pour effectuer une réécriture qui tient compte
de la variable REMOTE_USER
dans un contexte
niveau serveur (fichier apache2.conf
), vous devez
utiliser %{LA-U:REMOTE_USER}
; cette variable est
définie au cours des phases d'autorisation, qui interviennent
après la phase de traduction de l'URL (pendant
laquelle agit mod_rewrite).
Par contre, comme mod_rewrite implémente son contexte
niveau répertoire (fichier .htaccess
) via la
phase Fixup de l'API, et comme les phases d'autorisation
interviennent avant cette phase, vous ne pouvez
utiliser %{REMOTE_USER}
que
dans le contexte niveau serveur.
%{LA-F:variable}
pour
effectuer une sous-requête interne (basée sur un nom de
fichier), pour déterminer la valeur finale de
variable. La plupart du temps, elle est identique à
LA-U vue précédemment.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.
A savoir : expression de comparaison est une expression rationnelle compatible perl avec quelques extensions :
!
' (point d'exclamation) pour indiquer une
expression de non-correspondance.""
(deux guillemets),
chaîne de test est comparée à la chaîne vide.[
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} ^hote1 [OR] RewriteCond %{REMOTE_HOST} ^hote2 [OR] RewriteCond %{REMOTE_HOST} ^hote3 RewriteRule ...règles concernant tous ces hôtes...
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 basé sur le 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 le nom du fichier verrou utilisé pour la
synchronisation de RewriteMap |
---|---|
Syntaxe: | RewriteLock chemin du fichier verrou |
Contexte: | configuration du serveur |
Statut: | Extension |
Module: | mod_rewrite |
Cette directive définit le nom du fichier utilisé comme
fichier verrou de synchronisation nécessaire à mod_rewrite pour
communiquer avec les programmes liés à RewriteMap
. Définissez ce
fichier verrou dans un chemin local (et non sur un montage NFS)
si vous voulez utiliser un programme de comparaison pour la
réécriture. Il n'est pas nécessaire pour les autres types de
comparaison pour la réécriture.
Description: | Définit le nom du fichier utilisé pour la journalisation des traitements du moteur de réécriture |
---|---|
Syntaxe: | RewriteLog chemin du fichier journal |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_rewrite |
La directive RewriteLog
définit le nom
du fichier dans lequel le serveur journalise tout processus de
réécriture qu'il effectue. Si le nom ne commence pas par un
slash ('/
'), il est considéré comme relatif à la
Racine du serveur. Cette directive ne doit apparaître
qu'une seule fois dans la configuration du serveur.
/dev/null
pour désactiver la journalisation des processus de réécriture,
car même si le moteur de réécriture n'envoie plus sa sortie
dans un fichier, il continue à créer un fichier journal en
interne, ce qui va avoir pour effet de ralentir le
serveur sans fournir aucun avantage à l'administrateur !
Pour désactiver la journalisation, vous pouvez
soit supprimer ou commenter la directive
RewriteLog
, soit utiliser
RewriteLogLevel 0
!
Le format de fichier journal RewriteLog
se
présente comme suit :
Description | Exemple |
---|---|
Adresse IP de l'hôte distant | 192.168.200.166 |
Nom de login didtant | en général "-" |
nom d'authentification de l'utilisateur HTTP | nom d'utilisateur, ou "-" si non authentifié |
Date et heure de la requête | [28/Aug/2009:13:09:09 --0400] |
Serveur virtuel et son identifiant | [www.example.com/sid#84a650] |
Identifiant de la requête et indication éventuelle qu'il s'agit d'une sous-requête | [rid#9f0e58/subreq] |
Niveau de sévérité de l'entrée du journal | (2) |
Message d'erreur au format texte | forcing proxy-throughput with http://127.0.0.1:8080/index.html |
RewriteLog "/usr/local/var/apache/logs/rewrite.log"
Description: | Définit la verbosité du fichier journal utilisé par le moteur de réécriture |
---|---|
Syntaxe: | RewriteLogLevel niveau |
Défaut: | RewriteLogLevel 0 |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_rewrite |
La directive RewriteLogLevel
définit
le niveau de verbosité du fichier journal de réécriture. Le
niveau par défaut 0 signifie aucune journalisation, tandis que
9 ou plus signifie que pratiquement toutes les actions sont
journalisées.
Pour désactiver la journalisation des actions de réécriture, positionnez simplement niveau à 0. Ceci désactive toute journalisation des actions de réécriture.
RewriteLogLevel 3
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 d'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 :
txt
, source de la
correspondance : chemin du système de fichiers Unix vers un
fichier régulier valide
Il s'agit de la mise en oeuvre standard de la table de correspondance pour la réécriture où source de la correspondance est un fichier ASCII dont les différentes lignes sont soit des lignes vides, soit des lignes de commentaires (commençant par un caractère "#"), soit des paires de valeurs (une seule paire par ligne) comme suit :
mot-clé valeur de remplacement
## ## map.txt -- table de correspondance pour la réécriture ## Ralf.S.Engelschall rse # Bastard Operator From Hell (traduction à votre convenance) Mr.Joe.Average joe # Mr. Average
RewriteMap real-to-user txt:/chemin/vers/fichier/map.txt
rnd
,
source de la correspondance : chemin du système de fichiers
Unix vers un fichier régulier valide
Ce format se différencie du format texte standard
précédent par l'ajout d'un traitement supplémentaire : en
plus de la recherche de clés, le fichier est interprété en
tenant compte de la présence éventuelle dans les valeurs de
remplacement de caractères ``|
'' signifiant
``ou''. En d'autres termes, ces caractères ``|
''
permettent de spécifier un jeu de valeurs parmi lesquelles
la valeur de retour sera choisie aléatoirement. Par exemple,
vous pouvez utiliser les fichier de correspondance et
directives suivants pour mettre en oeuvre une répartition de
charge aléatoire entre plusieurs serveurs en arrière-plan,
via un mandataire inverse. Les images sont envoyées à un des
serveurs de l'ensemble "statique", tandis que tout le
reste est envoyé à un des serveurs de l'ensemble
"dynamique".
Exemple:
## ## map.txt -- correspondances pour la réécriture ## static www1|www2|www3|www4 dynamic www5|www6
RewriteMap serveurs rnd:/chemin/vers/fichier/map.txt
RewriteRule ^/(.*\.(png|gif|jpg)) http://${serveurs:static}/$1
[NC,P,L]
RewriteRule ^/(.*) http://${serveurs:dynamic}/$1 [P,L]
dbm[=type]
, source de la
correspondance : chemin du système de fichiers Unix vers un
fichier régulier valide
Ici, la source de la correspondance est un fichier binaire au format DBM contenant les mêmes données qu'un fichier au format Plein texte, mais selon une représentation particulière optimisée en vue d'une recherche très rapide. Le type peut être sdbm, gdbm, ndbm, ou db selon la configuration à la compilation . Si type est omis, la valeur retenue sera la valeur par défaut définie à la compilation.
La création du fichier dbm à partir d'un fichier texte s'effectue à l'aide de l'utilitaire httxt2dbm.
$ httxt2dbm -i fichier-source.txt -o fichier-dbm.map
int
,
source de la correspondance : fonction interne à Apache
Ici, la source de la correspondance est une fonction
interne à Apache. Les développeurs de modules peuvent
fournir des fonctions internes supplémentaires en les
enregistrant via l'API
ap_register_rewrite_mapfunc
. Les fonctions
fournies par défaut sont :
prg
,
source de la correspondance :
chemin du système de fichiers Unix vers un
fichier régulier valide
Ici, la source n'est pas un fichier de correspondances,
mais un programme. Pour le créer, vous pouvez utiliser le
langage de votre choix, mais le programme doit être un
exécutable (soit du code objet, soit un script
contenant le fameux
"#!/chemin/vers/interpréteur
" au début de sa
première ligne).
Ce programme est lancé une seule fois au démarrage du
serveur Apache, puis communique avec le moteur de réécriture
via ses entrée et sortie standards (stdin
et stdout
). A chaque recherche effectuée par la
fonction de correspondance, il reçoit sur son entrée standard
la clé à rechercher sous la forme d'une chaîne de caractères
terminée par le caractère "nouvelle ligne". Il doit ensuite
renvoyer sur sa sortie standard la valeur recherchée sous
la forme d'une chaîne de caractères terminée par le caractère
"nouvelle ligne", ou la chaîne de quatre
caractères ``NULL
'' en cas d'échec
(c'est à dire
si aucune valeur ne correspond à la clé fournie). Voici un
exemple de ce pourrait être un programme trivial qui
implémenterait une correspondance 1:1 (c'est à dire,
clé == valeur) :
Les programmes de réécriture externes ne seront pas lancés
s'ils ont été définis dans un contexte où la directive
RewriteEngine
n'a pas été définie à
on
.
#!/usr/bin/perl $| = 1; while (<STDIN>) { # ...insérer ici le code de transformation ou de recherche... print $_; }
Mais soyez très prudent :
stdout
est une erreur courante. Ceci est à
proscrire sous peine de créer une boucle infernale ! Pour
éviter ceci, on utilise ``$|=1
'' comme dans
l'exemple ci-dessus.RewriteLock
pour spécifier
un fichier verrou que mod_rewrite pourra utiliser pour
synchroniser les communications avec le programme de
correspondance. Par défaut, aucune synchronisation de ce
type n'est mise en oeuvre.La directive RewriteMap
peut
apparaître plusieurs fois. Utilisez une directive
RewriteMap
par fonction de correspondance
pour déclarer son fichier de correspondance pour la réécriture.
Bien que vous ne puissiez pas déclarer une
table de correspondance dans un contexte de répertoire, vous
pouvez bien entendu utiliser cette table dans un
contexte de répertoire.
mtime (date de modification)
du fichier
soit modifié, ou que le serveur soit redémarré. Ainsi, certaines
fonctions de correspondance dans les règles peuvent être utilisées pour
chaque requête. Cela ne pose pas problème, car la
recherche externe n'intervient qu'une seule fois !
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
du répertoire parent sont
héritées.
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 chemin de l'URL de la requête (%-decoded) ; les expressions suivantes sont comparées à la sortie de la dernière règle de réécriture qui a été appliquée.
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 à la règle RewriteRule
(par
exemple "app1/index.html" ou
"index.html" selon l'endroit où les directives sont définies).
Si vous voulez effectuer une comparaison en tenant compte du
nom d'hôte, du port ou de la chaîne de paramètres, utilisez une
directive RewriteCond
comportant 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. L'URL 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
. Flags est une liste de valeurs
déparées par des virgules, délimitée par des crochets, choisies
parmi les drapeaux de la table suivante. Vous trouverez plus de
détails et d'exemples, pour chaque drapeau, dans la documentation sur les drapeaux de
réécriture.
Flag and syntax | Function |
---|---|
B | Escape non-alphanumeric characters before applying the transformation. details ... |
chain|C | Rule is chained to the following rule. If the rule fails, the rule(s) chained to it will be skipped. details ... |
cookie|CO=NAME:VAL | Sets a cookie in the client browser. Full syntax is: CO=NAME:VAL:domain[:lifetime[:path[:secure[:httponly]]]] details ... |
discardpath|DPI | Causes the PATH_INFO portion of the rewritten URI to be discarded. details ... |
env|E=[!]VAR[:VAL] | Causes an environment variable VAR to be set (to the value VAL if provided). The form !VAR causes the environment variable VAR to be unset.details ... |
forbidden|F | Returns a 403 FORBIDDEN response to the client browser. details ... |
gone|G | Returns a 410 GONE response to the client browser. details ... |
Handler|H=Content-handler | Causes the resulting URI to be sent to the specified Content-handler for processing. details ... |
last|L | Stop the rewriting process immediately and don't apply any more rules. Especially note caveats for per-directory and .htaccess context (see also the END flag). details ... |
next|N | Re-run the rewriting process, starting again with the first rule, using the result of the ruleset so far as a starting point. details ... |
nocase|NC | Makes the pattern pattern comparison case-insensitive. details ... |
noescape|NE | Prevent mod_rewrite from applying hexcode escaping of special characters in the result of the rewrite. details ... |
nosubreq|NS | Causes a rule to be skipped if the current request is an internal sub-request. details ... |
proxy|P | Force the substitution URL to be internally sent as a proxy request. details ... |
passthrough|PT | Forces the resulting URI to be passed back to the URL
mapping engine for processing of other URI-to-filename
translators, such as Alias or
Redirect . details ... |
qsappend|QSA | Appends any query string created in the rewrite target to any query string that was in the original request URL. details ... |
redirect|R[=code] | Forces an external redirect, optionally with the specified HTTP status code. details ... |
skip|S=num | Tells the rewriting engine to skip the next num rules if the current rule matches. details ... |
type|T=MIME-type | Force the MIME-type of the target file to be the specified type. details ... |
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
(apache2.conf
)
pour la requête ``GET
/chemin/infochemin
'':
Règle Résultat de la substitution ---------------------------------------------- ---------------------------------- ^/chemin(.*) autre-chemin$1 non valide, non supporté ^/chemin(.*) autre-chemin$1 [R] non valide, non supporté ^/chemin(.*) autre-chemin$1 [P] non valide, non supporté ---------------------------------------------- ---------------------------------- ^/chemin(.*) /autre-chemin$1 /autre-chemin/infochemin ^/chemin(.*) /autre-chemin$1 [R] http://cet-hôte/autre-chemin/infochemin via redirection externe ^/chemin(.*) /autre-chemin$1 [P] n'a pas lieu d'être, non supporté ---------------------------------------------- ---------------------------------- ^/chemin(.*) http://cet-hôte/autre-chemin$1 /autre-chemin/infochemin ^/chemin(.*) http://cet-hôte/autre-chemin$1 [R] http://cet-hôte/autre-chemin/infochemin via redirection externe ^/chemin(.*) http://cet-hôte/autre-chemin$1 [P] n'a pas lieu d'être, non supporté ---------------------------------------------- ---------------------------------- ^/chemin(.*) http://autre hôte/autre-chemin$1 http://autre hôte/autre-chemin/infochemin via redirection externe ^/chemin(.*) http://autre hôte/autre-chemin$1 [R] http://autre hôte/autre-chemin/infochemin via redirection externe (le drapeau [R] est redondant) ^/chemin(.*) http://autre hôte/autre-chemin$1 [P] http://autre hôte/autre-chemin/infochemin via un mandataire interne
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