From c6a1e99829514f3a9aabee9256561ac291310b25 Mon Sep 17 00:00:00 2001
From: Rich Bowen Dans le cas des serveurs virtuels à base de noms, la valeur de
+ cette directive est extraite du serveur virtuel par défaut (le
+ premier de la liste) pour lequel la connexion correspondait à la
+ directive Dans le cas des serveurs virtuels à base de noms, la valeur de
+ cette directive est extraite du serveur virtuel par défaut (le
+ premier de la liste) pour lequel la connexion correspondait à la
+ directive Dans le cas des serveurs virtuels à base de noms, la valeur de
+ cette directive est extraite du serveur virtuel par défaut (le
+ premier de la liste) pour lequel la connexion correspondait à la
+ directive Fichiers .htaccess
+
+ Modules Apparentés Directives Apparentées .htaccess
ne doivent être utilisés
+ que si vous n'avez pas accès au fichier de configuration du serveur
+ principal. L'utilisation des fichiers .htaccess
+ ralentit le fonctionnement de votre serveur Apache. Il est toujours
+ préférable de définir les directives que vous pouvez inclure dans un
+ fichier .htaccess
dans une section Directory
, car elles produiront le
+ même effet avec de meilleures performances.Que sont ce fichiers, comment les utiliser ?
@@ -417,7 +425,7 @@ Includes - SSI)
AllowOverride None
n'affecte pas le répertoire où se
trouve votre fichier. Un bon test consiste à mettre des directives
dont la syntaxe est erronée dans votre ficher .htaccess
- et de redémarrer le serveur. Si aucune erreur n'est générée par le
+ et de recharger la page. Si aucune erreur n'est générée par le
serveur, il est pratiquement certain qu'une directive
AllowOverride None
affecte votre répertoire.
diff --git a/docs/manual/mod/core.html.fr b/docs/manual/mod/core.html.fr
index 7396ab743a..b5461e3781 100644
--- a/docs/manual/mod/core.html.fr
+++ b/docs/manual/mod/core.html.fr
@@ -2185,7 +2185,7 @@ envoy
requête HTTP
Syntaxe: LimitRequestFields nombre
-Défaut: LimitRequestFields 100
+Contexte: configuration du serveur Contexte: configuration du serveur, serveur virtuel Statut: Core
@@ -2220,6 +2220,13 @@ requ
LimitRequestFields 50
Module: core Avertissement
+ NameVirtualHost
.Syntaxe: LimitRequestFieldSize octets
-Défaut: LimitRequestFieldSize 8190
+Contexte: configuration du serveur Contexte: configuration du serveur, serveur virtuel Statut: Core
@@ -2261,6 +2268,13 @@ requ
Module: core Avertissement
+ NameVirtualHost
.Syntaxe: LimitRequestLine octets
-Défaut: LimitRequestLine 8190
+Contexte: configuration du serveur Contexte: configuration du serveur, serveur virtuel Statut: Core
@@ -2302,6 +2316,14 @@ HTTP
Module: core Avertissement
+ NameVirtualHost
.LimitXMLRequestBody Directive
diff --git a/docs/manual/mod/directives.html.es b/docs/manual/mod/directives.html.es
index a9f6d717ec..6df37dddf5 100644
--- a/docs/manual/mod/directives.html.es
+++ b/docs/manual/mod/directives.html.es
@@ -228,6 +228,7 @@
htpasswd
htdigest
mod_authn_file
utilisera la première occurence pour
vérifier le mot de passe.
Pour l'Authentification de base HTTP, on utilise
- l'utilitaire htpasswd
, installé avec la
- distribution binaire ou se trouvant dans src/support
,
- pour maintenir le fichier des mots de passe. Voir sa page de manuel pour plus de
+
Le format du mot de passe chiffré dépend du frontal
+ d'authentification utilisé (par exemple
+ mod_authn_basic
ou
+ mod_authn_digest
). Voir la documentation sur les
+ Formats de mots de
+ passe pour plus de détails.
Pour mod_authn_basic
, utilisez le programme
+ htpasswd
fourni avec la distribution binaire,
+ mais que vous trouverez aussi dans le répertoire
+ src/support
de l'arborescence des sources. Voir sa page de manuel pour plus de
détails. En bref :
On crée un fichier de mots de passe nom-fichier
avec
@@ -111,9 +120,8 @@ passe
très longue ; dans ce cas, il vaut mieux utiliser les fichiers DBM
avec la directive AuthDBMUserFile
.
Si vous utilisez l'Authentification HTTP à base de
- condensé, l'utilitaire htpasswd
ne convient
- pas. Vous devez utiliser htdigest
à la place.
+
Pour mod_authn_digest
, vous devez utiliser
+ le programme htdigest
.
Notez que vous ne pouvez pas mélanger des données utilisateur pour
l'Authentification HTTP à base de condensé et des données pour
l'Authentification de Base dans le même fichier.
Description: | Mise en cache de contenu référencé par un -URI. |
---|
Description: | Filtre de mise en cache HTTP conforme à la RFC 2616 |
---|---|
Statut: | Extension |
Identificateur de Module: | cache_module |
Fichier Source: | mod_cache.c |
mod_cache
implémente une mise en cache de
- contenu HTTP compatible RFC 2616 qui peut
- être utilisée pour mettre en cache des contenus locaux ou mandatés.
- mod_cache
requiert les services d'un ou plusieurs
- modules de gestion de stockage. La distribution Apache de base
+
mod_cache
implémente un filtre de mise
+ en cache de contenu HTTP conforme à la RFC 2616, avec
+ support de la mise en cache des réponses dont le contenu a été
+ négocié et comportant l'en-tête Vary.
La mise en cache conforme à la RFC 2616 fournit un mécanisme + permettant de vérifier si un contenu expiré ou dépassé est encore à + jour, et peut apporter un gain de performances significatif si le + serveur original supporte les requêtes + conditionnelles en prenant en compte l'en-tête de requête + HTTP If-None-Match. + Le contenu n'est ainsi régénéré que lorsqu'il a été modifié, et non + lorsqu'il a expiré.
+ +En tant que filtre, mod_cache
peut être placé
+ en face d'un contenu issu de tout gestionnaire, y compris
+ des fichiers à accès séquentiel (servis depuis un
+ disque lent mis en
+ cache sur un gros disque), la sortie d'un script
+ CGI ou d'un générateur de contenu
+ dynamique, ou du contenu mandaté depuis un autre
+ serveur.
Dans la configuration par défaut, mod_cache
+ place le filtre de mise en cache aussi loin que possible dans la
+ pile de filtres, utilisant le gestionnaire rapide
+ pour court-circuiter tout traitement par requête lors de l'envoi du
+ contenu au client. Dans ce mode opératoire,
+ mod_cache
peut être considéré comme un serveur
+ mandataire avec cache fixé en tête du serveur web, alors qu'il
+ s'exécute dans ce même serveur web.
Lorsque le gestionnaire rapide est désactivé via la directive
+ CacheQuickHandler
, il
+ devient possible d'insérer le filtre CACHE à un
+ point de la pile de filtres choisi par l'administrateur. Ceci permet
+ de mettre en cache un contenu avant que celui-ci ne soit
+ personnalisé par le filtre mod_include
, ou
+ éventuellement compressé par le filtre mod_deflate
.
Dans le mode de fonctionnement normal, mod_cache
+ peut être contrôlé par les en-têtes Cache-Control
+ et Pragma
+ envoyés par un client dans une requête, ou par un serveur dans une
+ réponse. Dans des circonstances exceptionnelles,
+ mod_cache
peut cependant être configuré pour
+ outrepasser ces en-têtes et forcer un comportement spécifique au
+ site, bien qu'un tel comportement sera limité à ce cache seulement,
+ et n'affectera pas les opérations des autres caches qui peuvent
+ s'insérer entre le client et le serveur, et ce type de configuration
+ ne doit donc être utiliser qu'en cas de nécessité absolue.
La RFC 2616 permet au cache de renvoyer des données périmées
+ pendant que l'entrée périmée correspondante est mise à jour depuis
+ le serveur original, et mod_cache
supporte cette
+ fonctionnalité lorsque la directive CacheLock
est configurée en
+ conséquence. De telles réponses comportent un en-tête HTTP Warning
+ contenant un code de réponse 110. La RFC 2616 permet aussi au cache
+ de renvoyer des données périmées lorsque la tentative de mise à jour
+ des données périmées renvoie une erreur 500 ou supérieure, et cette
+ fonctionnalité est supportée par défaut par
+ mod_cache
. De telles réponses comportent un en-tête HTTP Warning
+ contenant un code de réponse 111.
mod_cache
requiert les services d'un ou
+ plusieurs modules de gestion de stockage. La distribution Apache de base
inclut un module de gestion de stockage :
mod_disk_cache
htcacheclean
permet de lister et de supprimer les
+ URLs mises en cache, et de maintenir le cache en deçà de
+ certaines limites de taille et de nombre d'inodes.Les contenus sont stockés dans le cache et extraits de ce dernier - en utilisant une clé à base d'URI. Un contenu dont l'accès est - protégé ne sera pas mis en cache.
Pour de plus amples détails, une description, et des exemples, reportez-vous au Guide de la mise en cache.
@@ -212,7 +278,7 @@ cache possédant les plus hautes performances disponibles.Dans ce mode, le cache s'incruste devant le - serveur, comme si un mandataire de mise en cache indépendant RFC2616 + serveur, comme si un mandataire de mise en cache indépendant RFC 2616 était placé devant ce dernier.
Bien que que ce mode offre les meilleures performances, les diff --git a/docs/manual/mod/mod_disk_cache.html.fr b/docs/manual/mod/mod_disk_cache.html.fr index 582ac1ef54..07e9c34457 100644 --- a/docs/manual/mod/mod_disk_cache.html.fr +++ b/docs/manual/mod/mod_disk_cache.html.fr @@ -26,27 +26,40 @@ ja | ko
-Description: | Gestionnaire de stockage du cache de contenu à base -d'URIs |
---|
Description: | Module de stockage sur disque pour le filtre de mise en +cache HTTP. |
---|---|
Statut: | Extension |
Identificateur de Module: | disk_cache_module |
Fichier Source: | mod_disk_cache.c |
mod_disk_cache
implémente un gestionnaire de
- stockage sur disque. Il s'utilise principalement avec
- mod_cache
.
mod_cache
.
- Les contenus sont stockés dans le cache et extraits de ce dernier - en utilisant des clés à base d'URIs. Les contenus dont l'accès est - protégé ne sont pas mis en cache.
+Les en-têtes et corps des réponses mises en cache sont stockés + séparément sur le disque, dans une structure de répertoires basée + sur le condensé md5 de l'URL mise en cache.
-Le programme htcacheclean
permet de maintenir
- la taille du cache à un niveau maximum.
Plusieurs réponses au contenu négocié peuvent être stockées en + même temps, mais la mise en cache de contenus partiels n'est pas + supportée actuellement par ce module.
+ +Les mises à jour atomiques du cache pour les fichiers d'en-tête + et de corps peuvent être effectuées sans verrouillage en + enregistrant les numéros d'inode et de périphérique du fichier de + corps dans le fichier d'en-tête. Ceci implique que les entrées du + cache déplacées manuellement dans le cache seront ignorées.
+ +L'utilitaire htcacheclean
permet de lister et
+ de supprimer les URLs du cache, ou de maintenir le cache en deçà de
+ certaines limites de taille et/ou de nombre d'inodes. L'utilitaire
+ peut être exécuté à la demande, ou automatiquement pour assurer un
+ contrôle continu des tailles des répertoires.
mod_cache
doit être chargé pour que
- mod_disk_cache
puisse fonctionner.
mod_cache
doit être chargé avant
+ mod_disk_cache
pour que ce dernier puisse
+ fonctionner.
Lorsque la plate-forme la supporte, et si elle est activée via la
directive EnableSendfile
,
diff --git a/docs/manual/mod/mod_rewrite.html.fr b/docs/manual/mod/mod_rewrite.html.fr
index d8a2848a13..a07d00a3e7 100644
--- a/docs/manual/mod/mod_rewrite.html.fr
+++ b/docs/manual/mod/mod_rewrite.html.fr
@@ -29,30 +29,29 @@ r
à la volée
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
- (httpd.conf
) mais aussi au niveau du répertoire
- (.htaccess
), et peut inclure des arguments de chaîne
- de requête (query string) 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.
Le module mod_rewrite
utilise un moteur de
+ réécriture à base de règles, basé sur un interpréteur
+ d'expressions rationnelles, 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 @@ -64,92 +63,53 @@ d'Apache
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.
-
- Ces variables sont définies dans un contexte du niveau serveur, ce
- qui signifie qu'elles ne sont disponibles que dans un contexte de
- répertoire, si RewriteEngine
est positionné à
- on
dans un contexte de niveau serveur.
-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
-
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.
+
Vous trouverez de nombreux exemples d'utilisation courante (et - moins courante) de mod_rewrite dans le - Guide de réécriture, - et dans le - Guide de réécriture avancée.
+Pour extraire les traces spécifiques à
+ mod_rewrite
, affichez le fichier journal en
+ redirigeant la sortie vers grep :
+ tail -f error_log|fgrep '[rewrite:'
+
RewriteBase chemin URL
Voir utilisation pour plus d'informations.
Pas de valeur par défaut
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éinjecter 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 :
- + explicitement le chemin URL de base (et non le chemin du + répertoire dans le système de fichiers !) pour les réécritures dans un contexte + de répertoire. Lorsque vous utilisez une directiveRewriteRule
dans un fichier
+ .htaccess
, mod_rewrite
enlève le
+ préfixe de répertoire local avant d'effectuer le traitement, puis
+ réécrit ce qui reste de l'URL. Lorsque la réécriture est terminée,
+ mod_rewrite
rajoute automatiquement le préfixe de
+ répertoire local au chemin.
+
+ Cette directive est requise pour les réécritures
+ dans un contexte de répertoire défini via la directive
+ Alias
.
Si votre chemin URL n'existe pas réellement dans le système de
+ fichiers, ou ne trouve pas directement sous le répertoire défini
+ par la directive DocumentRoot
, vous devez utiliser la
+ directive RewriteBase
dans chaque fichier
+ .htaccess
où vous voulez utiliser des directives RewriteRule
.
L'exemple ci-dessous montre comment faire correspondre
+ http://example.com/mon-appli/index.html à
+ /home/www/exemple/nouveau_site.html dans un fichier
+ .htaccess
. On suppose que le contenu disponible à
+ http://example.com/ se situe sur le disque à
+ /home/www/exemple/.
-# -# /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 +# Le chemin URL utilisé pour arriver dans ce contexte, et non le chemin +# du système de fichiers +RewriteBase /mon-appli/ +RewriteRule ^index\.html$ nouveau_site.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).
-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 texte plat, les constructions étendues - suivantes :
- +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), 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
(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
(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é.
- %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 documentation de
- RewriteMap pour plus de détails.
+ ce sont des extensions de la forme ${nomTable:clé|défaut}
. Voir la href="#mapfunc">documentation sur 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 :
+ %{
NAME_OF_VARIABLE }
,
+ où NOM_DE_VARIABLE peut contenir une chaîne issue
+ de la liste suivante :
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. Vous trouverez
- dans ce qui suit quelques variables spécifiques
- à mod_rewrite.
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. Parmi les variables
+ spécifiques à mod_rewrite, ou trouve les suivantes :
IS_SUBREQ
API_VERSION
THE_REQUEST
REQUEST_URI
REQUEST_FILENAME
REQUEST_FILENAME
contient la
+ valeur de REQUEST_URI
.
HTTPS
mod_ssl
- soit chargé ou non).mod_ssl
soit chargé ou non.Autres points à connaître :
- +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
+
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 continue, - les valeurs des deux variables seront mises à jour en +
Si une substitution intervient et si la réécriture se + poursuit, la valeur des deux variables sera mise à jour en conséquence.
-Dans un contexte de niveau serveur (c'est à dire - avant que la requête soit mise en correspondance avec le système - de fichiers), SCRIPT_FILENAME et REQUEST_FILENAME ne peuvent pas - contenir le chemin complet dans le système de fichier local car - ce dernier n'est pas encore connu à ce niveau du traitement. - Dans ce cas, les deux variables contiendront initialement la - valeur de REQUEST_URI. Pour avoir accès au chemin complet de la - requête dans le système de fichiers local dans un contexte de - niveau serveur, utilisez une référence avant à base d'URL +
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 ê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.%{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, 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 httpd.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 pouvez vous contenter
- d'utiliser %{REMOTE_USER}
- 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.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.
-A savoir : - expression de comparaison est une - expression rationnelle compatible perl avec - quelques extensions :
+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.-RewriteCond %{REMOTE_HOST} ^hote1.* [OR] -RewriteCond %{REMOTE_HOST} ^hote2.* [OR] -RewriteCond %{REMOTE_HOST} ^hote3.* +RewriteCond %{REMOTE_HOST} ^host1 [OR] +RewriteCond %{REMOTE_HOST} ^host2 [OR] +RewriteCond %{REMOTE_HOST} ^host3 RewriteRule ...règles concernant tous ces hôtes...
-RewriteCond %{HTTP_USER_AGENT} ^Mozilla.*
+RewriteCond %{HTTP_USER_AGENT} ^Mozilla
RewriteRule ^/$ /homepage.max.html [L]
-RewriteCond %{HTTP_USER_AGENT} ^Lynx.*
+RewriteCond %{HTTP_USER_AGENT} ^Lynx
RewriteRule ^/$ /homepage.min.html [L]
RewriteRule ^/$ /homepage.std.html [L]
@@ -750,104 +742,6 @@ moteur de r
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
!
-
-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
-
La directive RewriteMap
définit une
Table de correspondance pour la réécriture que les
@@ -914,244 +808,36 @@ bases de donn
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ù la - 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 -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. Actuellement, vous ne pouvez pas créer - votre propre fonction, mais les fonctions suivantes - existent déjà :
- -httxt2dbm
(Détails ...).RewriteMap
: toupper, tolower, escape ou unescape
+ (Détails ...).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).
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
.
Voici un - exemple de ce pourrait être un programme trivial qui - implémenterait une correspondance 1:1 (c'est à dire, - clé == valeur) :
+-#!/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 (en langage Perl) ``$|=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.Requête SQL
- type de correspondance : dbd
ou
- fastdbd
,
- source de la correspondance : une requête SQL SELECT qui
- comporte un seul argument et renvoie une seule valeur.
Ici, on utilise mod_dbd
pour implémenter
- une correspondance pour la réécriture par recherche dans une
- base de données SQL. Deux modes sont possibles :
- fastdbd
met en cache les recherches dans la base
- de données en interne, alors que dbd
ne le fait
- pas. Ainsi, dbd
diminue les performances, mais
- donnera toujours une réponse actualisée, même si le contenu
- de la base de données est mise à jour, alors que
- fastdbd
est plus performant mais ne relira pas
- le contenu de la base de données tant que le serveur ne sera
- pas redémarré.
Si une requête renvoie plusieurs réponses, une de ces - dernières sera choisie aléatoirement.
-
-
-RewriteMap ma-requete "fastdbd:SELECT destination FROM rewrite WHERE source = %s"
-
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 !
-Vous trouverez plus de détails et de nombreux exemples dans le RewriteMap HowTo.
Le Modèle est d'abord comparé à la partie de l'URL après le nom d'hôte et le port, et avant la chaîne de - requête. Si vous souhaitez faire une comparaison sur le nom + requête.
+ +Dans un contexte de répertoire, Modèle est comparé à
+ ce qui reste de l'URL après suppression du préfixe qui a conduit
+ Apache httpd à la règle courante (voir la directive RewriteBase
). Le préfixe supprimé
+ se termine toujours par un slash, ce qui signifie que la
+ correspondance se fera toujours avec une chaîne qui ne commence
+ pas par un slash. Un Modèle contenant ^/
ne
+ correspondra jamais dans un contexte de répertoire.
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 les variables
+ comportant respectivement les variables
%{HTTP_HOST}
, %{SERVER_PORT}
, ou
- %{QUERY_STRING}
.
%{QUERY_STRING}
. Si vous désirez effectuer une
+ correspondance avec l'ensemble du chemin de l'URL dans un contexte
+ de répertoire (htaccess), utilisez la variable
+ %{REQUEST_URI}
.
Pour quelques conseils à propos des expressions rationnelles, voir le
@@ -1362,332 +1062,136 @@ substitution !
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 parmi les suivants :
B
' (références arrière échappées)Les URLs ne doivent pas être échappées pour pouvoir être - comparées par Apache, si bien que les références arrières - renverront une valeur non échappée au moment où elles seront - appliquées. En utilisant le drapeau B, les caractères non - alphanumériques des références arrières seront echappés. Par - exemple, considérons la règle :
-
- RewriteRule ^(/.*)$ /index.php?show=$1
-
Elle va faire correspondre /C++
à
- index.php?show=/C++
. Mais elle va aussi faire
- correspondre /C%2b%2b
à
- /index.php?show=/C++
, car le caractère
- %2b
n'a pas été échappé. Par contre, avec le
- drapeau B, la substitution s'effectuera vers
- /index.php?show=/C%2b%2b
.
Ce processus d'échappement est particulièrement nécessaire - dans le contexte du mandataire, où l'adresse d'arrière-plan ne - fonctionnera pas si elle se présente sous une forme - non échappée.
-chain|C
'
- (chaînage avec la règle suivante).www
'', dans un jeu de règles au niveau
- du répertoire, lorsque vous faites intervenir une redirection
- externe (où la partie ``.www
'' ne doit pas
- figurer !).cookie|CO=
NOM:VAL:domaine[:durée
- de vie[:chemin[:sécurité[:http
- seulement]]]]'
- (définit un cookie)HttpOnly
est utilisé, ce qui rend le cookie
- inaccessible au code JavaScript sur les navigateurs qui
- supportent ce dernier.discardpathinfo|DPI'
- (ne pas tenir compte de PATH_INFO)
Dans un contexte de répertoire, l'URI par rapport auquel
- chaque règle RewriteRule
effectue ses
- comparaisons est la concaténation de la valeur courante de l'URI
- et de PATH_INFO.
L'URI courant est soit l'URI initial tel qu'envoyé par le - client, soit le résultat d'un passage à travers le processus de - réécriture, soit le résultat de la règle précédente du processus - de réécriture courant.
- -Par contre, PATH_INFO qui est ajouté à l'URI avant chaque
- règle reflète la valeur qu'avait PATH_INFO avant le processus de
- réécriture. En conséquence, si de larges parties de l'URI sont
- retenues et copiées dans une chaîne de substitution au cours de
- multiples directives RewriteRule
, et ceci
- sans tenir compte de la part qui revient à PATH_INFO dans l'URI,
- il se peut que l'URI final se voit ajouter plusieurs copies de
- PATH_INFO.
Utilisez ce drapeau dans toute substitution où le PATH_INFO - résultant de la mise en correspondance précédente de cette - requête avec le système de fichiers ne présente pas d'intérêt. - Ce drapeau indique qu'il ne faut pas tenir compte du PATH_INFO - construit avant que le processus de réécriture courant ait - commencé. PATH_INFO ne sera pas recalculé avant que le processus - de réécriture courant se termine. Les règles suivantes - rencontrées au cours du processus ne verront que le résultat - direct des substitutions, sans ajout du PATH_INFO.
env|E=
VAR:VAL'
- (définit une variable d'environnement)$N
et %N
)
- qui seront évaluées. Vous pouvez utiliser ce drapeau plusieurs
- fois pour définir plusieurs variables. Les variables peuvent
- ensuite être déréférencées dans de nombreux cas, et le plus
- souvent depuis XSSI (via <!--#echo
- var="VAR"-->
) ou CGI ($ENV{'VAR'}
).
- Vous pouvez déréférencer la variable dans un modèle de
- directive RewriteCond ultérieure, en utilisant
- %{ENV:VAR}
. Ce drapeau permet de supprimer
- des informations d'une URL, tout en conservant la trace de
- ces informations.forbidden|F
' (force l'interdiction d'une
- URL)gone|G
' (signale la non-existence d'une
- URL)handler|H
=Gestionnaire de contenu'
- (impose un gestionnaire de contenu)ScriptAlias
du
- module mod_alias
, qui impose en interne le
- gestionnaire ``cgi-script
'' à tous les fichiers
- du répertoire correspondant.-
(tiret) comme
- substitution, faute de quoi la requête echouera.last|L
'
- (dernière règle)last
ou la commande C
- break
. Il permet d'éviter la réécriture par les
- règles suivantes d'une URL déjà réécrite. Rappelez-vous
- cependant que si une directive
- RewriteRule
génère une redirection
- interne (ce qui arrive fréquemment lors d'une réécriture dans
- un contexte de répertoire), la requête sera réinjectée et le
- processus de réécriture sera réitéré à partir de la
- première directive RewriteRule
.next|N
'
- (prochain round)next
ou la commande C continue
. Il
- permet de redémarrer le processus de réécriture - en se
- positionnant immédiatement au niveau de la première règle.
- Prenez garde à ne pas créer de bouclage
- infini !nocase|NC
'
- (insensible à la casse)noescape|NE
'
- (pas d'échappement de l'URI en sortie)
- RewriteRule ^/foo/(.*) /bar?arg=P1\%3d$1 [R,NE]
-
/foo/zed
' par la requête plus
- sure '/bar?arg=P1=zed
'.
- nosubreq|NS
'
- (sous-requêtes non concernées)Si ce drapeau est présent, le moteur de réécriture
- n'applique pas la règle si la requête courante est une
- sous-requête interne. Par exemples, des sous-requêtes sont
- générées en interne par Apache lorsque
- mod_dir
essaie de trouver des
- informations à propos d'éventuels fichiers de répertoire par
- défaut (fichiers index.xxx
). Dans le cas d'une
- sous-requête, ce n'est pas toujours utile, et peut même
- provoquer des erreurs si l'ensemble du jeu de règles est
- appliqué. Ce drapeau permet d'exclure certaines règles.
Pour déterminer si l'on doit appliquer une règle ou pas, - si une URL est préfixée par un script CGI, pour forcer son - traitement par le script CGI, vous allez probablement - rencontrer des problèmes (ou tout du moins une surcharge - significative) avec les sous-requêtes. Dans ce cas, - utilisez ce drapeau
-proxy|P
' (impose le mandataire)http://
nom d'hôte) pouvant être traitée
- par le module proxy d'Apache. Si ce n'est pas le cas, le
- module proxy vous renverra une erreur. Utilisez ce drapeau
- pour implémenter de manière plus puissante la directive ProxyPass, pour mettre
- en correspondance un contenu distant dans l'espace de
- nommage du serveur local.
-
- Note: mod_proxy
doit être activé pour
- pouvoir utiliser ce drapeau..
passthrough|PT
'
- (passage au gestionnaire suivant)filename
au
- champ uri
de la structure interne
- request_rec
. Ce drapeau n'est qu'une astuce
- permettant un traitement supplémentaire de la sortie des
- directives RewriteRule
, en utilisant
- Alias
, ScriptAlias
,
- Redirect
, ou d'autres directives en provenance
- de divers traducteurs URI/nom de fichier. Par exemple, pour
- réécrire /abc
vers /def
avec
- mod_rewrite
, puis /def
vers
- /ghi
avec mod_alias
:
-
- RewriteRule ^/abc(.*) /def$1 [PT]
- Alias /def /ghi
-
PT
est omis,
- mod_rewrite
va réécrire
- uri=/abc/...
vers filename=/def/...
- comme tout traducteur URI/nom de fichier compatible avec
- l'API doit le faire. Puis, mod_alias
va tenter
- une transition URI vers nom de fichier, et va échouer.
-
- Note: Vous devez utiliser ce drapeau si vous
- voulez mélanger des directives en provenance de différents
- modules qui effectuent une traduction
- URL/nom de fichier. Un exemple typique est
- l'utilisation conjointe de mod_alias
et de
- mod_rewrite
.
Le drapeau PT
rend implicite la présence du
- drapeau L
flag : la réécriture sera stoppée afin
- de transmettre la requête à la phase suivante du
- traitement.
qsappend|QSA
'
- (ajout d'une chaîne de requête - query string)redirect|R
- [=code]' (force une redirection)Préfixe la chaîne de substitution par
- http://hôte[:port]/
(ce qui fait de la nouvelle
- URL un URI) pour forcer une redirection externe. Si aucun
- code n'est défini, une réponse HTTP 302 (MOVED
- TEMPORARILY) sera renvoyée. Si vous voulez renvoyer un autre
- code de réponse, spécifiez simplement le nombre approprié ou
- utilisez un des noms symboliques suivants : temp
- (défaut), permanent
ou seeother
.
- Vous pouvez utiliser ce drapeau pour que les règles mettent
- l'URL sous forme canonique et la renvoient au client, pour
- traduire ``/~
'' en ``/u/
'', ou pour
- ajouter systématiquement un slash à
- /u/
utilisateur, etc...
- Note: Si vous utilisez ce drapeau,
- assurez-vous que le champ de substitution est une URL
- valide ! Si ce n'est pas le cas, vous serez redirigé vers
- une URL invalide. Souvenez-vous que, s'il est seul, ce
- drapeau va seulement préfixer l'URL par
- http://hôte[:port]/
, et que le processus de
- réécriture va se poursuivre. En général, vous voudrez plutôt
- stopper la réécriture à ce point, et rediriger immédiatement.
- Pour stopper la réécriture, vous pouvez ajouter le drapeau
- 'L'.
Bien qu'on utilise en général ce drapeau pour les
- redirections, on peut spécifier tout code de statut valide.
- Si le code de statut est en dehors de la gamme des codes de
- redirection (300-399), la chaîne de Substitution est
- supprimée et le processus de réécriture stoppé comme si le
- drapeau L
était présent.
skip|S
=num'
- (saute la/les règle(s) suivantes)skip=N
, où N
- est le nombre de règles contenues dans le bloc "else" (ce qui est
- un comportement différent de celui du drapeau 'chain|C' !).type|T
=type MIME'
- (force le type MIME)-
(tiret) comme substitution, faute de quoi le
- type MIME défini à l'aide de ce drapeau sera perdu à cause d'un
- rejeu du traitement en interne.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]]]]] + détails ... + | +
discardpathinfo|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). 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 créée dans la cible de + réécriture à toute chaîne de paramètres présente dans l'URL de la + requête originale. 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 ... | +
tyle|T=Type-MIME | +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
@@ -1746,40 +1250,73 @@ d'aucune utilit
/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 -
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
@@ -1789,41 +1326,77 @@ d'aucune utilit
/chemin/chemin-local/infochemin'':
-Règle Résultat de la substitution ----------------------------------------------- ---------------------------------- -^chemin-local(.*) autre-chemin$1 /chemin/autre-chemin/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 | +
Expires
+Expires
headersExpires
header configured
+Expires
header configured
by MIME typemod_ext_filter
optionsmod_ext_filter
optionsmod_filter
base
for imagemap filesbase
for imagemap filesPOST
data)HSE_APPEND_LOG_PARAMETER
requests from
+POST
data)HSE_APPEND_LOG_PARAMETER
requests from
ISAPI extensions to the error logHSE_APPEND_LOG_PARAMETER
requests from
+HSE_APPEND_LOG_PARAMETER
requests from
ISAPI extensions to the query fieldfree()
mod_mime
to treat path_info
+mod_mime
to treat path_info
components as part of the filenameAllow
and Deny
are
evaluated.Via
HTTP response
+Via
HTTP response
header for proxied requestsServer
HTTP response
+Server
HTTP response
headerLast-Modified
headers are generated by the
+Last-Modified
headers are generated by the
server.TRACE
+TRACE
requestsmime.types
filemime.types
fileExpires
Çì´õ¸¦ »ý¼ºÇÑ´ÙExpires
Çì´õ°ªÀ» ¼³Á¤ÇÑ´ÙExpires
Çì´õ¸¦ »ý¼ºÇÑ´ÙExpires
Çì´õ°ªÀ» ¼³Á¤ÇÑ´Ùmod_ext_filter
¿É¼ÇÀ» ¼³Á¤ÇÑ´Ùmod_ext_filter
¿É¼ÇÀ» ¼³Á¤ÇÑ´Ùmod_filter
base
±âº»°ªbase
±âº»°ªPOST
data)HSE_APPEND_LOG_PARAMETER
+POST
data)HSE_APPEND_LOG_PARAMETER
¿äûÀ» ¿À·ù ·Î±×¿¡ ±â·ÏÇÑ´ÙHSE_APPEND_LOG_PARAMETER
+HSE_APPEND_LOG_PARAMETER
¿äûÀ» ÁúÀǹ®ÀÚ¿¿¡ ±â·ÏÇÑ´Ùfree()
mod_mime
to treat path_info
+mod_mime
to treat path_info
components as part of the filenameAllow
and Deny
are
evaluated.Via
HTTP response
+Via
HTTP response
header for proxied requestsServer
HTTP response
+Server
HTTP response
headerLast-Modified
headers are generated by the
+Last-Modified
headers are generated by the
server.TRACE
+TRACE
requestsmime.types
filemime.types
filemod_proxy
ProxyPass
est maintenant configurée
+ de la manière la plus optimale dans les sections Location
ou LocationMatch
, et offre un gain de
+ performances important par rapport à la syntaxe traditionnelle à
+ deux paramètres lorsqu'elle est présente en grand nombre.mod_proxy_fcgi
Un autre drapeau, [END], permet non seulement d'interrompre le cycle +courant du processus de réécriture, mais aussi d'empêcher toute +réécriture ultérieure dans le contexte de répertoire (htaccess). Ceci ne +s'applique pas aux nouvelles requêtes résultant de redirections +externes.
+Dans l'exemple donné ici, toute requête est réécrite en
index.php
, la requête originale étant ajoutée comme chaîne
de requête en argument à index.php
; cependant, la
diff --git a/docs/manual/rewrite/index.html.fr b/docs/manual/rewrite/index.html.fr
index 81f0d255b8..1f52b513db 100644
--- a/docs/manual/rewrite/index.html.fr
+++ b/docs/manual/rewrite/index.html.fr
@@ -23,73 +23,74 @@
tr
-- -``Ce qui est super avec mod_rewrite, c'est qui permet - autant de configuration et de flexibilité que Sendmail. - L'inconvénient de mod_rewrite, c'est qu'il permet autant de - configuration et de flexibilité que Sendmail.''
- --- Brian Behlendorf
- -
- Groupe Apache
-- -``Malgré les tonnes d'exemples et de documentations, - mod_rewrite relève de la magie vaudoue. De la magie vaudoue super - géniale, mais de la magie vaudoue.''
- --- Brian Moore
- -
- bem@news.cmc.net
Bienvenue dans mod_rewrite, le couteau suisse de la - manipulation d'URL !
- -Ce module met en oeuvre un moteur de réécriture à base de - règles (basé sur un interpréteur d'expressions rationnelles) pour - réécrire les URLs issues des requêtes à la volée. Il fournit un + +
mod_rewrite
permet de modifier les requêtes
+ entrantes dynamiquement, en fonction de règles manipulant des expressions rationnelles. Vous pouvez
+ ainsi relier des URLs arbitraires à votre propre structure d'URLs
+ interne comme vous le souhaitez.
Il fournit un mécanisme de manipulation d'URL particulièrement souple et puissant en supportant un nombre illimité de règles et de conditions attachées à chaque règle. Les manipulations d'URLs - peuvent dépendre de tests variés : par exemple, les URLs peuvent + peuvent dépendre de tests variés : les URLs peuvent être finement caractérisées en fonction de variables du serveur, de variables d'environnement, d'en-têtes HTTP, de repères - temporels, ou même de requêtes vers des bases de données externes - sous différents formats.
+ temporels, de recherches dans des bases de données + externes, ou même de requêtes vers des bases de données externes + et de différents gestionnaires ou programmes externes. -Ce module agit sur l'ensemble des URLs (la partie chemin - incluse) non seulement dans le contexte du serveur principal +
Les règles de réécriture peuvent agir sur l'ensemble des URLs (la partie chemin
+ et la chaîne de paramètres) et peuvent être utilisées dans le contexte du serveur principal
(httpd.conf
), mais aussi dans le contexte des
+ serveurs virtuels (sections <VirtualHost>
), ou dans le
+ contexte des
répertoires (fichiers .htaccess
et blocs
- <Directory>
), et peut même générer des chaînes
- de requête comme résultat. Le résultat réécrit peut conduire à un
+ <Directory>
. Le résultat
+ réécrit peut conduire vers d'autres règles à un
traitement secondaire interne, une redirection vers une requête
- externe ou même l'envoi vers un serveur mandataire.
Mais toutes ces fonctionnalités et cette souplesse ont un - inconvénient : la complexité. N'espérez donc pas comprendre ce - module dans les détails en un seul jour.
+mod_rewrite étant très puissant, il peut par + conséquent être très complexe. Ce document + complè la documentation de + référence, et est sensé alléger un + peu cette complexité, et présenter des exemples largement + commentés, ainsi que des situations courantes que vous + pourrez traiter avec mod_rewrite. Mais nous voulons aussi vous + montrer des situations où vous ne devrez pas utiliser + mod_rewrite, et lui préférer d'autres + fonctionnalités standard d'Apache, évitant ainsi + d'entrer dans une complexité inutile.
- - - -