From: Lucien Gentis
.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 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.xml.fr b/docs/manual/mod/core.xml.fr
index 4b2e37da347..cc32985c67e 100644
--- a/docs/manual/mod/core.xml.fr
+++ b/docs/manual/mod/core.xml.fr
@@ -1,7 +1,7 @@
-
+
@@ -2249,7 +2249,7 @@ host
requête HTTP
nombre est un entier de 0 (nombre de champs illimité)
@@ -2283,6 +2283,13 @@ requête HTTP
LimitRequestFields 50
+ 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
Cette directive permet de définir le nombre maximum
@@ -2323,6 +2330,13 @@ requête HTTP
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
Cette directive permet de définir la taille maximale autorisée
@@ -2362,6 +2376,14 @@ HTTP
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
Pour l'Authentification de base HTTP, on utilise
- l'utilitaire src/support,
- pour maintenir le fichier des mots de passe. Voir sa Le format du mot de passe chiffré dépend du frontal
+ d'authentification utilisé (par exemple
+
Pour src/support de l'arborescence des sources. Voir sa page de manuel pour plus de
détails. En bref :
Si vous utilisez l'Authentification HTTP à base de
- condensé, l'utilitaire
Pour
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,
Dans la configuration par défaut,
Lorsque le gestionnaire rapide est désactivé via la directive
+
Dans le mode de fonctionnement normal,
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
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.
@@ -190,7 +262,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.xml.fr b/docs/manual/mod/mod_disk_cache.xml.fr
index 1689551507a..092ed7c157b 100644
--- a/docs/manual/mod/mod_disk_cache.xml.fr
+++ b/docs/manual/mod/mod_disk_cache.xml.fr
@@ -1,7 +1,7 @@
-
+
@@ -25,27 +25,40 @@
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
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
Lorsque la plate-forme la supporte, et si elle est activée via la
directive 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
- ( Le module Vous trouverez d'avantage de détails, discussions et exemples
dans la
@@ -63,80 +62,43 @@ d'Apache
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 ' Ce module conserve le contenu de deux variables d'environnement
- CGI/SSI additionnelles (non standards) nommées
- 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.
- Par défaut, les hôtes virtuels n'héritent pas de la
- configuration de Ceux qui sont familiers avec les versions précédentes de
+ 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 à
+ 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.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.\$' ; ceci empêche mod_rewrite de le
- traiter comme une référence arrière.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.
- 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 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/
-
-
- RewriteOptions Inherit
- trace1 à
+ trace8. Le niveau de journalisation peut être défini de
+ manière spécifique à debug aucune action n'est journalisée, alors qu'elles
+ le sont pratiquement toutes au niveau trace8.trace2 qu'à des fins de débogage !
+ RewriteLog et
+ RewriteLogLevel. Elles ont été en effet remplacées
+ par une configuration de la journalisation par module, comme
+ mentionné plus haut.
+
La directive /'), 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
- RewriteLogLevel 0 !
-La directive
Pour désactiver la journalisation des actions de réécriture, - positionnez simplement niveau à 0. Ceci désactive - toute journalisation des actions de réécriture.
- -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 à
La directive
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 --
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 --
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.
- -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à :
- -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
- 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.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 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.
-La directive
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 !
-httxt2dbm (Détails ...).RewriteMap: toupper, tolower, escape ou unescape
+ (Détails ...).Vous trouverez plus de détails et de nombreux exemples dans le RewriteMap HowTo.
La directive .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
-
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.
.htaccess où vous voudrez utiliser des
-directives 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 directive.htaccess, Cette directive est requise pour les réécritures
+ dans un contexte de répertoire défini via la directive
+
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 .htaccess où vous voulez utiliser des directives
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
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
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.
+ >${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_SUBREQAPI_VERSIONTHE_REQUESTREQUEST_URIREQUEST_FILENAMEREQUEST_FILENAME contient la
+ valeur de REQUEST_URI.
HTTPSAutres 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_recdu 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.%{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 %{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.%{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]
@@ -1238,17 +921,33 @@ RewriteRule ^/$ /homepage.std.html [L]
Qu'est-ce qui est comparé ?
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
- document Introduction à
+ document Introduction à
mod_rewrite.
Dans mod_rewrite, on peut aussi utiliser le caractère NON
@@ -1381,335 +1080,155 @@ 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 :
-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
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
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)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
- 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)/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
- 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:
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
- /def vers
- /ghi avec 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
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 |
+
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 @@ -1772,40 +1291,73 @@ d'aucune utilité et n'est pas supporté.
/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
@@ -1815,41 +1367,77 @@ d'aucune utilité et n'est pas supporté.
-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) +
| 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 | +
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.xml.fr b/docs/manual/rewrite/index.xml.fr
index b82a3f7438a..aebea24bad0 100644
--- a/docs/manual/rewrite/index.xml.fr
+++ b/docs/manual/rewrite/index.xml.fr
@@ -1,7 +1,7 @@
-
+
@@ -28,76 +28,81 @@
-- -``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 + +
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 .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.
+ externe ou même l'envoi vers un serveur mandataire, en fonction + des drapeaux que vous attachez aux + règles + +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.
+