From: Vincent Deffontaines Date: Fri, 9 Mar 2012 23:19:10 +0000 (+0000) Subject: A package of rewrite docs translated into french X-Git-Tag: 2.4.2~224 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=b1ce79da05885dfb6b5ea0fc72994a48710b4688;p=apache A package of rewrite docs translated into french git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1299097 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/rewrite/access.html b/docs/manual/rewrite/access.html index dad5faec44..0ce25e0e0a 100644 --- a/docs/manual/rewrite/access.html +++ b/docs/manual/rewrite/access.html @@ -3,3 +3,7 @@ URI: access.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 + +URI: access.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/rewrite/access.html.fr b/docs/manual/rewrite/access.html.fr new file mode 100644 index 0000000000..861e808264 --- /dev/null +++ b/docs/manual/rewrite/access.html.fr @@ -0,0 +1,316 @@ + + + +Utiliser mod_rewrite pour le contrôle d'accès - Serveur Apache HTTP + + + + + +
<-
+
+Apache > Serveur HTTP > Documentation > Version 2.4 > Rewrite

Utiliser mod_rewrite pour le contrôle d'accès

+
+

Langues Disponibles:  en  | + fr 

+
+ + +

Ce document est un complément à la documentation de référence de +mod_rewrite. Il explique comment utiliser +mod_rewrite pour contrôler l'accès à diverses +ressources, ainsi que d'autres techniques en rapport. Il contient de +nombreux exemples d'utilisation courante de mod_rewrite avec une +description détaillée de leur fonctionnement.

+ +
Vous devez vous attacher à comprendre le +fonctionnement des exemples, car la plupart d'entre eux ne +fonctionneront pas sur votre système si vous vous contentez de les +copier/coller dans vos fichiers de configuration.
+ +
+ +
top
+
+

Blocage du référencement à chaud (Hotlinking) d'images

+ + + +
+
Description :
+ +
+

Cette technique vous permet d'interdire à d'autres sites + d'inclure directement vos images dans leurs pages. On fait + souvent référence à cette pratique sous le nom de + référencement à chaud (Hotlinking) qui entraîne l'utilisation + de votre bande passante pour servir des contenus faisant + partie du site de quelqu'un d'autre.

+
+ +
Solution :
+ +
+

Cette technique repose sur la valeur de la variable + optionnelle HTTP_REFERER. Certaines personnes + pourront donc contourner cette limitation. Pour la plupart des + utilisateurs cependant, la requête échouera, en ce sens que + l'image ne sera pas affichée depuis le site tiers.

+

Il y a plusieurs manières de gérer cette situation.

+ +

Dans le premier exemple, nous rejetons tout simplement la + requête si elle ne provenait pas d'une page appartenant à notre + site. Pour les besoins de cet exemple, nous supposons que le nom + de votre site est www.example.com.

+ + + +

+RewriteCond %{HTTP_REFERER} !^$
+RewriteCond %{HTTP_REFERER} !www.example.com [NC]
+RewriteRule \.(gif|jpg|png)$ - [F,NC] +

+ +

Dans le second exemple, plutôt que de rejeter la requête, + nous affichons une autre image à la place.

+ +

+RewriteCond %{HTTP_REFERER} !^$
+RewriteCond %{HTTP_REFERER} !www.example.com [NC]
+RewriteRule \.(gif|jpg|png)$ /images/go-away.png [R,NC] +

+ +

Dans le troisième exemple, nous redirigeons la requête vers + une image appartenant à un autre site.

+ + +

+RewriteCond %{HTTP_REFERER} !^$
+RewriteCond %{HTTP_REFERER} !www.example.com [NC]
+RewriteRule \.(gif|jpg|png)$ http://other.example.com/image.gif [R,NC] +

+

De tous ces exemples, les deux derniers semblent les plus + efficaces pour faire en sorte que les gens arrêtent de + référencer vos images à chaud, car il ne verront pas les images + qu'ils s'attendent à voir.

+ +
+ +
Discussion :
+ +
+

Si vous ne voulez pas rediriger la requête, mais + simplement interdire l'accès à la ressource, vous pouvez y + parvenir sans utiliser mod_rewrite :

+ +

+ SetEnvIf Referer exemple\.com localreferer
+ <FilesMatch \.(jpg|png|gif)$>
+ Order deny,allow
+ Deny from all
+ Allow from env=localreferer
+ </FilesMatch> +

+
+
+ +
top
+
+

Blocage des robots

+ + + +
+
Description :
+ +
+

+ Dans cet exemple, nous allons discuter d'une méthode permettant + de bloquer les requêtes persistentes en provenance d'un robot + particulier, ou d'un navigateur.

+ +

La méthode classique pour exclure un robot consiste à définir + un fichier, /robots.txt qui spécifie les parties de + votre site web pour lesquelles vous voulez exclure les robots. + Malheureusement, certains robots ne tiennent pas compte de ces + fichiers. +

+ +

Notez qu'il existe des méthodes d'exclusion qui n'utilisent + pas mod_rewrite. Notez aussi que toute technique qui repose sur + le contenu de la chaîne client USER_AGENT peut être + contournée très facilement car cette chaîne de caractères peut + être modifiée.

+
+ +
Solution :
+ +
+

On utilise un jeu de règles qui spécifie le répertoire à + protéger, ainsi que la chaîne client USER_AGENT qui + identifie le robot indésirable ou envahissant.

+ +

Dans cet exemple, nous bloquons un robot nommé + Vilain_Robot pour le répertoire + /secret/fichiers. Si vous voulez bloquer ce client + seulement depuis une source particulière, vous pouvez aussi + spécifier un intervalle d'adresses IP.

+ +

+RewriteCond %{HTTP_USER_AGENT} ^Vilain_Robot
+RewriteCond %{REMOTE_ADDR} =123\.45\.67\.[8-9]
+RewriteRule ^/secret/fichiers/ - [F] +

+
+ +
Discussion :
+ +
+

+ Vous pouvez cependant parvenir au même résultat sans utiliser + mod_rewrite via la méthode alternative suivante : +

+

+ SetEnvIfNoCase User-Agent ^Vilain_Robot interdit
+ <Location /secret/fichiers>
+ Order allow,deny
+ Allow from all
+ Deny from env=interdit
+ </Location> +

+

+ Comme indiqué plus haut, il est aisé de contourner cette + technique, simplement en modifiant le contenu de l'en-tête + USER_AGENT. Si vous subissez une attaque en règle, + vous allez devoir réfléchir à un blocage à un niveau supérieur, + par exemple une règle de filtrage de votre pare-feu. +

+ +
+ +
+ +
top
+
+

Rejet des clients contenus dans une liste noire

+ + + +
+
Description :
+ +
+

Nous voulons interdire l'accès à notre serveur aux clients + contenus dans une liste noire similaire à + hosts.deny.

+
+ +
Solution :
+ +
+

+RewriteEngine on
+RewriteMap hosts-deny txt:/chemin/vers/hosts.deny
+RewriteCond ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND} !=NOT-FOUND [OR]
+RewriteCond ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND} !=NOT-FOUND
+RewriteRule ^ - [F] +

+ +

+##
+## hosts.deny
+##
+## ATTENTION! Ceci est une table de correspondances, non une liste,
+## même si elle est traitée comme telle. mod_rewrite
+## l'interprète comme une liste de paires clé/valeur, et
+## chaque entrée doit au moins posséder une valeur par
+## défaut "-".
+
+193.102.180.41 -
+bsdti1.sdm.de -
+192.76.162.40 -
+

+
+ +
Discussion :
+
+

+ La seconde condition RewriteCond présuppose que HostNameLookups est + défini à On, de façon à ce que les adresses IP des clients puissent + être résolues. Dans le cas contraire, vous devez supprimer la + seconde condition, ainsi que le drapeau [OR] de la + première. +

+
+
+ +
top
+
+

Aiguillage basé sur l'en-tête Referer

+ + + +
+
Description :
+ +
+

Redirige les requêtes en fonction du Referer de provenance de + la requête, avec des cibles différentes pour chaque Referer.

+
+ +
Solution :
+ +
+

Le jeu de règles suivant utilise un fichier de correspondances pour + associer chaque Referer à une cible de redirection.

+ +

+RewriteMap deflector txt:/chemin/vers/deflector.map
+
+RewriteCond %{HTTP_REFERER} !=""
+RewriteCond ${deflector:%{HTTP_REFERER}} =-
+RewriteRule ^ %{HTTP_REFERER} [R,L]
+
+RewriteCond %{HTTP_REFERER} !=""
+RewriteCond ${deflector:%{HTTP_REFERER}|NOT-FOUND} !=NOT-FOUND
+RewriteRule ^ ${deflector:%{HTTP_REFERER}} [R,L] +

+ +

Le fichier de correspondances contient les cibles de + redirection associées à chaque Referer, ou, si nous voulons + simplement rediriger les requêtes vers leur Referer, un "-" est + inscrit dans le fichier de correspondances :

+ +

+##
+## deflector.map
+##
+
+http://www.mauvais-gars.example.com/mauvais/index.html -
+http://www.mauvais-gars.example.com/mauvais/index2.html -
+http://www.mauvais-gars.example.com/mauvais/index3.html http://quelque-part.example.com/ +

+ +
+
+ +
+
+

Langues Disponibles:  en  | + fr 

+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/access.xml.fr b/docs/manual/rewrite/access.xml.fr new file mode 100644 index 0000000000..76ada8704b --- /dev/null +++ b/docs/manual/rewrite/access.xml.fr @@ -0,0 +1,322 @@ + + + + + + + + + + + Rewrite + +Utiliser mod_rewrite pour le contrôle d'accès + + + +

Ce document est un complément à la documentation de référence de +mod_rewrite. Il explique comment utiliser +mod_rewrite pour contrôler l'accès à diverses +ressources, ainsi que d'autres techniques en rapport. Il contient de +nombreux exemples d'utilisation courante de mod_rewrite avec une +description détaillée de leur fonctionnement.

+ +Vous devez vous attacher à comprendre le +fonctionnement des exemples, car la plupart d'entre eux ne +fonctionneront pas sur votre système si vous vous contentez de les +copier/coller dans vos fichiers de configuration. + +
+Documentation du module mod_rewrite +Introduction à mod_rewrite +Redirection et remise en +correspondance + +Serveurs virtuels +Serveurs mandataires +Utilisation de RewriteMap +Techniques avancées +Quand ne pas utiliser mod_rewrite + +
+ + Blocage du référencement à chaud (Hotlinking) d'images + +
+
Description :
+ +
+

Cette technique vous permet d'interdire à d'autres sites + d'inclure directement vos images dans leurs pages. On fait + souvent référence à cette pratique sous le nom de + référencement à chaud (Hotlinking) qui entraîne l'utilisation + de votre bande passante pour servir des contenus faisant + partie du site de quelqu'un d'autre.

+
+ +
Solution :
+ +
+

Cette technique repose sur la valeur de la variable + optionnelle HTTP_REFERER. Certaines personnes + pourront donc contourner cette limitation. Pour la plupart des + utilisateurs cependant, la requête échouera, en ce sens que + l'image ne sera pas affichée depuis le site tiers.

+

Il y a plusieurs manières de gérer cette situation.

+ +

Dans le premier exemple, nous rejetons tout simplement la + requête si elle ne provenait pas d'une page appartenant à notre + site. Pour les besoins de cet exemple, nous supposons que le nom + de votre site est www.example.com.

+ + + + +RewriteCond %{HTTP_REFERER} !^$
+RewriteCond %{HTTP_REFERER} !www.example.com [NC]
+RewriteRule \.(gif|jpg|png)$ - [F,NC] +
+ +

Dans le second exemple, plutôt que de rejeter la requête, + nous affichons une autre image à la place.

+ + +RewriteCond %{HTTP_REFERER} !^$
+RewriteCond %{HTTP_REFERER} !www.example.com [NC]
+RewriteRule \.(gif|jpg|png)$ /images/go-away.png [R,NC] +
+ +

Dans le troisième exemple, nous redirigeons la requête vers + une image appartenant à un autre site.

+ + + +RewriteCond %{HTTP_REFERER} !^$
+RewriteCond %{HTTP_REFERER} !www.example.com [NC]
+RewriteRule \.(gif|jpg|png)$ http://other.example.com/image.gif [R,NC] +
+

De tous ces exemples, les deux derniers semblent les plus + efficaces pour faire en sorte que les gens arrêtent de + référencer vos images à chaud, car il ne verront pas les images + qu'ils s'attendent à voir.

+ +
+ +
Discussion :
+ +
+

Si vous ne voulez pas rediriger la requête, mais + simplement interdire l'accès à la ressource, vous pouvez y + parvenir sans utiliser mod_rewrite :

+ + + SetEnvIf Referer exemple\.com localreferer
+ <FilesMatch \.(jpg|png|gif)$>
+ Order deny,allow
+ Deny from all
+ Allow from env=localreferer
+ </FilesMatch> +
+
+
+ +
+ +
+ + Blocage des robots + +
+
Description :
+ +
+

+ Dans cet exemple, nous allons discuter d'une méthode permettant + de bloquer les requêtes persistentes en provenance d'un robot + particulier, ou d'un navigateur.

+ +

La méthode classique pour exclure un robot consiste à définir + un fichier, /robots.txt qui spécifie les parties de + votre site web pour lesquelles vous voulez exclure les robots. + Malheureusement, certains robots ne tiennent pas compte de ces + fichiers. +

+ +

Notez qu'il existe des méthodes d'exclusion qui n'utilisent + pas mod_rewrite. Notez aussi que toute technique qui repose sur + le contenu de la chaîne client USER_AGENT peut être + contournée très facilement car cette chaîne de caractères peut + être modifiée.

+
+ +
Solution :
+ +
+

On utilise un jeu de règles qui spécifie le répertoire à + protéger, ainsi que la chaîne client USER_AGENT qui + identifie le robot indésirable ou envahissant.

+ +

Dans cet exemple, nous bloquons un robot nommé + Vilain_Robot pour le répertoire + /secret/fichiers. Si vous voulez bloquer ce client + seulement depuis une source particulière, vous pouvez aussi + spécifier un intervalle d'adresses IP.

+ + +RewriteCond %{HTTP_USER_AGENT} ^Vilain_Robot
+RewriteCond %{REMOTE_ADDR} =123\.45\.67\.[8-9]
+RewriteRule ^/secret/fichiers/ - [F] +
+
+ +
Discussion :
+ +
+

+ Vous pouvez cependant parvenir au même résultat sans utiliser + mod_rewrite via la méthode alternative suivante : +

+ + SetEnvIfNoCase User-Agent ^Vilain_Robot interdit
+ <Location /secret/fichiers>
+ Order allow,deny
+ Allow from all
+ Deny from env=interdit
+ </Location> +
+

+ Comme indiqué plus haut, il est aisé de contourner cette + technique, simplement en modifiant le contenu de l'en-tête + USER_AGENT. Si vous subissez une attaque en règle, + vous allez devoir réfléchir à un blocage à un niveau supérieur, + par exemple une règle de filtrage de votre pare-feu. +

+ +
+ +
+ +
+ +
+ + Rejet des clients contenus dans une liste noire + +
+
Description :
+ +
+

Nous voulons interdire l'accès à notre serveur aux clients + contenus dans une liste noire similaire à + hosts.deny.

+
+ +
Solution :
+ +
+ +RewriteEngine on
+RewriteMap hosts-deny txt:/chemin/vers/hosts.deny
+RewriteCond ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND} !=NOT-FOUND [OR]
+RewriteCond ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND} !=NOT-FOUND
+RewriteRule ^ - [F] +
+ + +##
+## hosts.deny
+##
+## ATTENTION! Ceci est une table de correspondances, non une liste,
+## même si elle est traitée comme telle. mod_rewrite
+## l'interprète comme une liste de paires clé/valeur, et
+## chaque entrée doit au moins posséder une valeur par
+## défaut "-".
+
+193.102.180.41 -
+bsdti1.sdm.de -
+192.76.162.40 -
+
+
+ +
Discussion :
+
+

+ La seconde condition RewriteCond présuppose que HostNameLookups est + défini à On, de façon à ce que les adresses IP des clients puissent + être résolues. Dans le cas contraire, vous devez supprimer la + seconde condition, ainsi que le drapeau [OR] de la + première. +

+
+
+ +
+ +
+ + Aiguillage basé sur l'en-tête Referer + +
+
Description :
+ +
+

Redirige les requêtes en fonction du Referer de provenance de + la requête, avec des cibles différentes pour chaque Referer.

+
+ +
Solution :
+ +
+

Le jeu de règles suivant utilise un fichier de correspondances pour + associer chaque Referer à une cible de redirection.

+ + +RewriteMap deflector txt:/chemin/vers/deflector.map
+
+RewriteCond %{HTTP_REFERER} !=""
+RewriteCond ${deflector:%{HTTP_REFERER}} =-
+RewriteRule ^ %{HTTP_REFERER} [R,L]
+
+RewriteCond %{HTTP_REFERER} !=""
+RewriteCond ${deflector:%{HTTP_REFERER}|NOT-FOUND} !=NOT-FOUND
+RewriteRule ^ ${deflector:%{HTTP_REFERER}} [R,L] +
+ +

Le fichier de correspondances contient les cibles de + redirection associées à chaque Referer, ou, si nous voulons + simplement rediriger les requêtes vers leur Referer, un "-" est + inscrit dans le fichier de correspondances :

+ + +##
+## deflector.map
+##
+
+http://www.mauvais-gars.example.com/mauvais/index.html -
+http://www.mauvais-gars.example.com/mauvais/index2.html -
+http://www.mauvais-gars.example.com/mauvais/index3.html http://quelque-part.example.com/ +
+ +
+
+ +
+ + +
diff --git a/docs/manual/rewrite/access.xml.meta b/docs/manual/rewrite/access.xml.meta index aa67bf49f9..cda0183580 100644 --- a/docs/manual/rewrite/access.xml.meta +++ b/docs/manual/rewrite/access.xml.meta @@ -8,5 +8,6 @@ en + fr diff --git a/docs/manual/rewrite/advanced.html b/docs/manual/rewrite/advanced.html index 64d0639fcf..c82f1dc096 100644 --- a/docs/manual/rewrite/advanced.html +++ b/docs/manual/rewrite/advanced.html @@ -3,3 +3,7 @@ URI: advanced.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 + +URI: advanced.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/rewrite/advanced.html.fr b/docs/manual/rewrite/advanced.html.fr new file mode 100644 index 0000000000..9a7a204292 --- /dev/null +++ b/docs/manual/rewrite/advanced.html.fr @@ -0,0 +1,524 @@ + + + +Techniques avancées de réécriture avec mod_rewrite - Serveur Apache HTTP + + + + + +
<-
+
+Apache > Serveur HTTP > Documentation > Version 2.4 > Rewrite

Techniques avancées de réécriture avec mod_rewrite

+
+

Langues Disponibles:  en 

+
+ + +

Ce document complète la documentation de référence du + module mod_rewrite. Il présente un certain nombre + de techniques avancées quant à + l'utilisation de mod_rewrite.

+ +
Notez que la plupart des exemples ne fonctionneront +pas en l'état dans la configuration particulière de votre serveur ; il +est donc important de bien comprendre leur fonctionnement, plutôt que de +simplement les copier/coller dans votre configuration.
+ +
+ +
top
+
+

Distribution de la charge entre plusieurs serveurs + d'arrière-plan en fonction de l'adresse IP

+ + + +
+
Description :
+ +
+

La fragmentation ou "sharding" est une technique courante de + distribution de la charge du serveur ou de l'espace de stockage. + Quand on utilise cette méthode, un serveur frontal utilise l'URL + pour répartir de manière appropriée les utilisateurs et objets + entre différents serveurs d'arrière-plan.

+
+ +
Solution :
+ +
+

On maintient une table de correspondance entre utilisateurs et + serveurs cibles dans des fichiers externes. Ces derniers se + présentent comme suit :

+ +

+utilisateur1 serveur_physique_utilisateur1
+utilisateur2 serveur_physique_utilisateur2
+: : +

+ +

Tout ceci est enregistré dans un fichier + correspondances-utilisateurs-serveurs. Le but est de + faire correspondre

+ +

+/u/utilisateur1/chemin +

+ +

avec

+ +

+http://serveur_physique_utilisateur1/u/utilisateur/chemin +

+ +

il n'est ainsi pas nécessaire que tous les chemins URL soient + valides sur tous les serveurs physiques d'arrière-plan. Le jeu de + règles suivant fait tout ceci pour nous, en s'appuyant sur les + fichiers de correspondances, en supposant que serveur0 est un + serveur par défaut qui sera utilisé lorsqu'un utilisateur ne + possèdera pas d'entrée dans la table de correspondances :

+ +

+RewriteEngine on
+
+RewriteMap utilisateurs-serveurs +txt:/chemin/vers/correspondances-utilisateurs-serveurs
+
+RewriteRule ^/u/([^/]+)/?(.*) http://${utilisateurs-serveurs:$1|server0}/u/$1/$2 +

+
+
+ +

Voir la documentation de RewriteMap pour une description plus + approfondie de la syntaxe de cette directive.

+ +
top
+
+

Régéneration de contenu à la volée

+ + + +
+
Description :
+ +
+

Nous voulons générer du contenu de manière dynamique, mais le + conserver de manière statique lorsqu'il a été généré. La règle + suivante vérifie l'existence du fichier statique, et le génère + s'il est absent. Les fichiers statiques peuvent être supprimés + périodiquement si on le désire (par exemple via cron), et seront + régénérés à la demande.

+
+ +
Solution :
+ +
+ À cet effet, on utilise le jeu de règles suivant : + +

+# Cet exemple n'est valable que dans un contexte de répertoire
+RewriteCond %{REQUEST_URI} !-U
+RewriteRule ^(.+)\.html$ /regenerate_page.cgi [PT,L] +

+ +

L'opérateur -U permet de déterminer si la chaîne + de test (dans ce cas REQUEST_URI) est une URL valide. + Pour ce faire, il utilise une sous-requête. Si cette sous-requête + échoue, ou en d'autres termes, si la ressource demandée n'existe pas, + cette règle invoque le programme CGI + /regenerate_page.cgi qui génère la ressource + demandée et la sauvegarde dans le répertoire des documents, de + façon à ce qu'une copie statique puisse être servie lors d'une + demande ultérieure.

+ +

De cette façon, les documents qui ne sont pas mis à jour + régulièrement peuvent être servis sous une forme statique. Si ces + documents doivent être réactualisés, on peut les supprimer du + répertoire des documents, et ils seront ainsi régénérés à la + prochaine demande.

+
+
+ +
top
+
+

Répartition de charge

+ + + +
+
Description :
+ +
+

Nous voulons répartir la charge de manière aléatoire entre + plusieurs serveurs en utilisant mod_rewrite.

+
+ +
Solution :
+ +
+

Pour y parvenir, nous allons utiliser la directive RewriteMap et une liste de + serveurs.

+ +

+RewriteEngine on
+RewriteMap lb rnd:/chemin/vers/liste-serveurs.txt
+
+RewriteRule ^/(.*) http://${lb:serveurs}/$1 [P,L] +

+ +

liste-serveurs.txt contiendra la liste des serveurs :

+ +

+## liste-serveurs.txt
+
+serveurs un.example.com|deux.example.com|trois.example.com
+

+ +

Si vous voulez qu'un serveur se voit confier d'avantage de charge que +les autres, faites le figurer plusieurs fois dans la liste.

+ +
+ +
Discussion
+
+

Apache possède un module de répartition de charge - +mod_proxy_balancer - beaucoup plus souple et présentant +plus de fonctionnalités dans ce domaine que mod_rewrite.

+
+
+ +
top
+
+

Actualisation automatique d'un document

+ + + + + +
+
Description :
+ +
+

Lorsque nous créons une page web complexe, ne serait-il pas + souhaitable que le navigateur web actualise automatiquement la + page chaque fois que nous en sauvegardons une nouvelle version + à partir de notre éditeur ? Impossible ?

+
+ +
Solution :
+ +
+

Non ! Nous allons pour cela combiner la fonctionnalité MIME + multipart, la fonctionnalité NPH du serveur web et la + puissance de mod_rewrite pour la manipulation + d'URLs. Tout d'abord, nous définissons une nouvelle + fonctionnalité pour les URLs : l'ajout de + :refresh à toute URL fait que la 'page' est + actualisée chaque fois que la ressource est mise à jour dans + le système de fichiers.

+ +

+RewriteRule ^(/[uge]/[^/]+/?.*):refresh /interne/cgi/apache/nph-refresh?f=$ +

+ +

Nous appelons maintenant cette URL

+ +

+/u/foo/bar/page.html:refresh +

+ +

ce qui entraîne en interne l'invocation de l'URL

+ +

+/interne/cgi/apache/nph-refresh?f=/u/foo/bar/page.html +

+ +

Il ne reste plus qu'à écrire le script NPH-CGI. Bien que l'on + écrive habituellement dans ces cas "laissé à la charge du + lecteur à titre d'exercice", ;-) je vous l'offre, aussi.

+ +
+#!/sw/bin/perl
+##
+##  nph-refresh -- script NPH/CGI pour l'actualisation automatique de
+##  pages
+##  Copyright (c) 1997 Ralf S. Engelschall, All Rights Reserved.
+##
+$| = 1;
+
+#   éclate la variable QUERY_STRING
+@pairs = split(/&/, $ENV{'QUERY_STRING'});
+foreach $pair (@pairs) {
+($name, $value) = split(/=/, $pair);
+$name =~ tr/A-Z/a-z/;
+$name = 'QS_' . $name;
+$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
+eval "\$$name = \"$value\"";
+}
+$QS_s = 1 if ($QS_s eq '');
+$QS_n = 3600 if ($QS_n eq '');
+if ($QS_f eq '') {
+print "HTTP/1.0 200 OK\n";
+print "Content-type: text/html\n\n";
+print "&lt;b&gt;ERREUR&lt;/b&gt;: Aucun fichier fourni\n";
+exit(0);
+}
+if (! -f $QS_f) {
+print "HTTP/1.0 200 OK\n";
+print "Content-type: text/html\n\n";
+print "&lt;b&gt;ERREUR&lt;/b&gt;: Fichier $QS_f non trouvé\n";
+exit(0);
+}
+
+sub print_http_headers_multipart_begin {
+print "HTTP/1.0 200 OK\n";
+$bound = "ThisRandomString12345";
+print "Content-type: multipart/x-mixed-replace;boundary=$bound\n";
+&print_http_headers_multipart_next;
+}
+
+sub print_http_headers_multipart_next {
+print "\n--$bound\n";
+}
+
+sub print_http_headers_multipart_end {
+print "\n--$bound--\n";
+}
+
+sub displayhtml {
+local($buffer) = @_;
+$len = length($buffer);
+print "Content-type: text/html\n";
+print "Content-length: $len\n\n";
+print $buffer;
+}
+
+sub readfile {
+local($file) = @_;
+local(*FP, $size, $buffer, $bytes);
+($x, $x, $x, $x, $x, $x, $x, $size) = stat($file);
+$size = sprintf("%d", $size);
+open(FP, "&lt;$file");
+$bytes = sysread(FP, $buffer, $size);
+close(FP);
+return $buffer;
+}
+
+$buffer = &readfile($QS_f);
+&print_http_headers_multipart_begin;
+&displayhtml($buffer);
+
+sub mystat {
+local($file) = $_[0];
+local($time);
+
+($x, $x, $x, $x, $x, $x, $x, $x, $x, $mtime) = stat($file);
+return $mtime;
+}
+
+$mtimeL = &mystat($QS_f);
+$mtime = $mtime;
+for ($n = 0; $n &lt; $QS_n; $n++) {
+while (1) {
+    $mtime = &mystat($QS_f);
+    if ($mtime ne $mtimeL) {
+        $mtimeL = $mtime;
+        sleep(2);
+        $buffer = &readfile($QS_f);
+        &print_http_headers_multipart_next;
+        &displayhtml($buffer);
+        sleep(5);
+        $mtimeL = &mystat($QS_f);
+        last;
+    }
+    sleep($QS_s);
+}
+}
+
+&print_http_headers_multipart_end;
+
+exit(0);
+
+##EOF##
+
+
+
+ +
top
+
+

Répertoires Home structurés

+ + + +
+
Description :
+ +
+

Certains sites avec des milliers d'utilisateurs organisent + les répertoires utilisateurs de manière structurée, c'est à + dire que chaque répertoire utilisateur se trouve dans un + sous-répertoire dont le nom commence (par exemple) par le + premier caractère du nom de l'utilisateur. Ainsi, + /~larry/chemin correspond à + /home/l/larry/public_html/chemin, alors + que /~waldo/chemin correspond à + /home/w/waldo/public_html/chemin.

+
+ +
Solution :
+ +
+

On utilise le jeu de règles suivant pour développer les + URLs avec tilde selon l'organisation structurée précédente.

+ +

+RewriteEngine on
+RewriteRule ^/~(([a-z])[a-z0-9]+)(.*) /home/$2/$1/public_html$3 +

+
+
+ +
top
+
+

Redirection des ancrages

+ + + +
+
Description :
+ +
+

Par défaut, la redirection vers un ancrage HTML ne fonctionne + pas, car mod_rewrite échappe le caractère # en le + transformant en %23, ce qui rend la redirection + inopérante.

+
+ +
Solution :
+ +
+

On utilise le drapeau [NE] dans la règle + RewriteRule. NE signifie "No Escape". +

+
+ +
Discussion :
+
Cette technique fonctionne bien entendu pour tout autre + caractère spécial que mod_rewrite, par défaut, code pour insertion + dans une URL.
+
+ +
top
+
+

Réécriture dépendant de l'heure

+ + + +
+
Description :
+ +
+

Nous voulons servir des contenus différents selon l'heure du + jour en utilisant mod_rewrite.

+
+ +
Solution :
+ +
+

Il existe de nombreuses variables nommées + TIME_xxx utilisables dans les conditions de + réécriture. Utilisées en conjonction avec les modèles de + comparaison lexicographique spéciaux <STRING, + >STRING et =STRING, elles + permettent d'effectuer des redirections dépendant de + l'heure :

+ +

+RewriteEngine on
+RewriteCond %{TIME_HOUR}%{TIME_MIN} >0700
+RewriteCond %{TIME_HOUR}%{TIME_MIN} <1900
+RewriteRule ^foo\.html$ foo.jour.html [L]
+RewriteRule ^foo\.html$ foo.nuit.html +

+ +

Avec cet exemple, l'URL foo.html renvoie + le contenu de foo.jour.html durant le + créneau horaire 07:01-18:59, et le contenu de + foo.nuit.html le reste du temps.

+ +
mod_cache, les mandataires + intermédiaires et les navigateurs peuvent chacun mettre en cache + les réponses et ainsi afficher une des deux pages en dehors de + la fenêtre de temps configurée. On peut utiliser + mod_expires pour contourner ce problème. Il est + cependant bien plus commode de servir un contenu dynamique, et + de le personnaliser en fonction de l'heure du jour.
+
+ +
top
+
+

Définir des variables d'environnement en fonction de + certaines parties de l'URL

+ + + +
+
Description :
+ +
+

Ici, nous voulons conserver une certaine forme de statut + lorsqu'une réécriture a eu lieu. Par exemple, vous souhaitez + consigner le fait que cette réécriture a eu lieu, et vous servir + plus tard de cette information pour déterminer si une requête sera + concernée par cette réécriture. Pour y parvenir, on peut utiliser + une variable d'environnement.

+
+ +
Solution :
+ +
+

Utiliser le drapeau [E] pour définir une variable + d'environnement.

+ +

+RewriteEngine on
+RewriteRule ^/cheval/(.*) /poney/$1 [E=rewritten:1] +

+ +

Plus loin dans votre jeu de règles, vous pouvez vérifier le + contenu de cette variable d'environnement via une directive + RewriteCond :

+ +

+RewriteCond %{ENV:rewritten} =1 +

+ +
+
+ +
+
+

Langues Disponibles:  en 

+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/advanced.xml.fr b/docs/manual/rewrite/advanced.xml.fr new file mode 100644 index 0000000000..c9edff1a70 --- /dev/null +++ b/docs/manual/rewrite/advanced.xml.fr @@ -0,0 +1,532 @@ + + + + + + + + + + + Rewrite + +Techniques avancées de réécriture avec mod_rewrite + + + +

Ce document complète la documentation de référence du + module mod_rewrite. Il présente un certain nombre + de techniques avancées quant à + l'utilisation de mod_rewrite.

+ +Notez que la plupart des exemples ne fonctionneront +pas en l'état dans la configuration particulière de votre serveur ; il +est donc important de bien comprendre leur fonctionnement, plutôt que de +simplement les copier/coller dans votre configuration. + +
+Documentation du module +Introduction à mod_rewrite +Redirection et remise en +correspondance +Contrôler l'accès +serveurs virtuels +serveurs mandataires +Utilisation de RewriteMap + +Quand ne pas utiliser mod_rewrite + +
+ + Distribution de la charge entre plusieurs serveurs + d'arrière-plan en fonction de l'adresse IP + +
+
Description :
+ +
+

La fragmentation ou "sharding" est une technique courante de + distribution de la charge du serveur ou de l'espace de stockage. + Quand on utilise cette méthode, un serveur frontal utilise l'URL + pour répartir de manière appropriée les utilisateurs et objets + entre différents serveurs d'arrière-plan.

+
+ +
Solution :
+ +
+

On maintient une table de correspondance entre utilisateurs et + serveurs cibles dans des fichiers externes. Ces derniers se + présentent comme suit :

+ + +utilisateur1 serveur_physique_utilisateur1
+utilisateur2 serveur_physique_utilisateur2
+: : +
+ +

Tout ceci est enregistré dans un fichier + correspondances-utilisateurs-serveurs. Le but est de + faire correspondre

+ + +/u/utilisateur1/chemin + + +

avec

+ + +http://serveur_physique_utilisateur1/u/utilisateur/chemin + + +

il n'est ainsi pas nécessaire que tous les chemins URL soient + valides sur tous les serveurs physiques d'arrière-plan. Le jeu de + règles suivant fait tout ceci pour nous, en s'appuyant sur les + fichiers de correspondances, en supposant que serveur0 est un + serveur par défaut qui sera utilisé lorsqu'un utilisateur ne + possèdera pas d'entrée dans la table de correspondances :

+ + +RewriteEngine on
+
+RewriteMap utilisateurs-serveurs +txt:/chemin/vers/correspondances-utilisateurs-serveurs
+
+RewriteRule ^/u/([^/]+)/?(.*) http://${utilisateurs-serveurs:$1|server0}/u/$1/$2 +
+
+
+ +

Voir la documentation de RewriteMap pour une description plus + approfondie de la syntaxe de cette directive.

+ +
+ +
+ + Régéneration de contenu à la volée + +
+
Description :
+ +
+

Nous voulons générer du contenu de manière dynamique, mais le + conserver de manière statique lorsqu'il a été généré. La règle + suivante vérifie l'existence du fichier statique, et le génère + s'il est absent. Les fichiers statiques peuvent être supprimés + périodiquement si on le désire (par exemple via cron), et seront + régénérés à la demande.

+
+ +
Solution :
+ +
+ À cet effet, on utilise le jeu de règles suivant : + + +# Cet exemple n'est valable que dans un contexte de répertoire
+RewriteCond %{REQUEST_URI} !-U
+RewriteRule ^(.+)\.html$ /regenerate_page.cgi [PT,L] +
+ +

L'opérateur -U permet de déterminer si la chaîne + de test (dans ce cas REQUEST_URI) est une URL valide. + Pour ce faire, il utilise une sous-requête. Si cette sous-requête + échoue, ou en d'autres termes, si la ressource demandée n'existe pas, + cette règle invoque le programme CGI + /regenerate_page.cgi qui génère la ressource + demandée et la sauvegarde dans le répertoire des documents, de + façon à ce qu'une copie statique puisse être servie lors d'une + demande ultérieure.

+ +

De cette façon, les documents qui ne sont pas mis à jour + régulièrement peuvent être servis sous une forme statique. Si ces + documents doivent être réactualisés, on peut les supprimer du + répertoire des documents, et ils seront ainsi régénérés à la + prochaine demande.

+
+
+ +
+ +
+ + Répartition de charge + +
+
Description :
+ +
+

Nous voulons répartir la charge de manière aléatoire entre + plusieurs serveurs en utilisant mod_rewrite.

+
+ +
Solution :
+ +
+

Pour y parvenir, nous allons utiliser la directive RewriteMap et une liste de + serveurs.

+ + +RewriteEngine on
+RewriteMap lb rnd:/chemin/vers/liste-serveurs.txt
+
+RewriteRule ^/(.*) http://${lb:serveurs}/$1 [P,L] +
+ +

liste-serveurs.txt contiendra la liste des serveurs :

+ + +## liste-serveurs.txt
+
+serveurs un.example.com|deux.example.com|trois.example.com
+
+ +

Si vous voulez qu'un serveur se voit confier d'avantage de charge que +les autres, faites le figurer plusieurs fois dans la liste.

+ +
+ +
Discussion
+
+

Apache possède un module de répartition de charge - +mod_proxy_balancer - beaucoup plus souple et présentant +plus de fonctionnalités dans ce domaine que mod_rewrite.

+
+
+ +
+ +
+ + Actualisation automatique d'un document + + + +
+
Description :
+ +
+

Lorsque nous créons une page web complexe, ne serait-il pas + souhaitable que le navigateur web actualise automatiquement la + page chaque fois que nous en sauvegardons une nouvelle version + à partir de notre éditeur ? Impossible ?

+
+ +
Solution :
+ +
+

Non ! Nous allons pour cela combiner la fonctionnalité MIME + multipart, la fonctionnalité NPH du serveur web et la + puissance de mod_rewrite pour la manipulation + d'URLs. Tout d'abord, nous définissons une nouvelle + fonctionnalité pour les URLs : l'ajout de + :refresh à toute URL fait que la 'page' est + actualisée chaque fois que la ressource est mise à jour dans + le système de fichiers.

+ + +RewriteRule ^(/[uge]/[^/]+/?.*):refresh /interne/cgi/apache/nph-refresh?f=$ + + +

Nous appelons maintenant cette URL

+ + +/u/foo/bar/page.html:refresh + + +

ce qui entraîne en interne l'invocation de l'URL

+ + +/interne/cgi/apache/nph-refresh?f=/u/foo/bar/page.html + + +

Il ne reste plus qu'à écrire le script NPH-CGI. Bien que l'on + écrive habituellement dans ces cas "laissé à la charge du + lecteur à titre d'exercice", ;-) je vous l'offre, aussi.

+ +
+#!/sw/bin/perl
+##
+##  nph-refresh -- script NPH/CGI pour l'actualisation automatique de
+##  pages
+##  Copyright (c) 1997 Ralf S. Engelschall, All Rights Reserved.
+##
+$| = 1;
+
+#   éclate la variable QUERY_STRING
+@pairs = split(/&/, $ENV{'QUERY_STRING'});
+foreach $pair (@pairs) {
+($name, $value) = split(/=/, $pair);
+$name =~ tr/A-Z/a-z/;
+$name = 'QS_' . $name;
+$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
+eval "\$$name = \"$value\"";
+}
+$QS_s = 1 if ($QS_s eq '');
+$QS_n = 3600 if ($QS_n eq '');
+if ($QS_f eq '') {
+print "HTTP/1.0 200 OK\n";
+print "Content-type: text/html\n\n";
+print "&lt;b&gt;ERREUR&lt;/b&gt;: Aucun fichier fourni\n";
+exit(0);
+}
+if (! -f $QS_f) {
+print "HTTP/1.0 200 OK\n";
+print "Content-type: text/html\n\n";
+print "&lt;b&gt;ERREUR&lt;/b&gt;: Fichier $QS_f non trouvé\n";
+exit(0);
+}
+
+sub print_http_headers_multipart_begin {
+print "HTTP/1.0 200 OK\n";
+$bound = "ThisRandomString12345";
+print "Content-type: multipart/x-mixed-replace;boundary=$bound\n";
+&print_http_headers_multipart_next;
+}
+
+sub print_http_headers_multipart_next {
+print "\n--$bound\n";
+}
+
+sub print_http_headers_multipart_end {
+print "\n--$bound--\n";
+}
+
+sub displayhtml {
+local($buffer) = @_;
+$len = length($buffer);
+print "Content-type: text/html\n";
+print "Content-length: $len\n\n";
+print $buffer;
+}
+
+sub readfile {
+local($file) = @_;
+local(*FP, $size, $buffer, $bytes);
+($x, $x, $x, $x, $x, $x, $x, $size) = stat($file);
+$size = sprintf("%d", $size);
+open(FP, "&lt;$file");
+$bytes = sysread(FP, $buffer, $size);
+close(FP);
+return $buffer;
+}
+
+$buffer = &readfile($QS_f);
+&print_http_headers_multipart_begin;
+&displayhtml($buffer);
+
+sub mystat {
+local($file) = $_[0];
+local($time);
+
+($x, $x, $x, $x, $x, $x, $x, $x, $x, $mtime) = stat($file);
+return $mtime;
+}
+
+$mtimeL = &mystat($QS_f);
+$mtime = $mtime;
+for ($n = 0; $n &lt; $QS_n; $n++) {
+while (1) {
+    $mtime = &mystat($QS_f);
+    if ($mtime ne $mtimeL) {
+        $mtimeL = $mtime;
+        sleep(2);
+        $buffer = &readfile($QS_f);
+        &print_http_headers_multipart_next;
+        &displayhtml($buffer);
+        sleep(5);
+        $mtimeL = &mystat($QS_f);
+        last;
+    }
+    sleep($QS_s);
+}
+}
+
+&print_http_headers_multipart_end;
+
+exit(0);
+
+##EOF##
+
+
+
+ +
+ +
+ + Répertoires Home structurés + +
+
Description :
+ +
+

Certains sites avec des milliers d'utilisateurs organisent + les répertoires utilisateurs de manière structurée, c'est à + dire que chaque répertoire utilisateur se trouve dans un + sous-répertoire dont le nom commence (par exemple) par le + premier caractère du nom de l'utilisateur. Ainsi, + /~larry/chemin correspond à + /home/l/larry/public_html/chemin, alors + que /~waldo/chemin correspond à + /home/w/waldo/public_html/chemin.

+
+ +
Solution :
+ +
+

On utilise le jeu de règles suivant pour développer les + URLs avec tilde selon l'organisation structurée précédente.

+ + +RewriteEngine on
+RewriteRule ^/~(([a-z])[a-z0-9]+)(.*) /home/$2/$1/public_html$3 +
+
+
+ +
+ +
+ + Redirection des ancrages + +
+
Description :
+ +
+

Par défaut, la redirection vers un ancrage HTML ne fonctionne + pas, car mod_rewrite échappe le caractère # en le + transformant en %23, ce qui rend la redirection + inopérante.

+
+ +
Solution :
+ +
+

On utilise le drapeau [NE] dans la règle + RewriteRule. NE signifie "No Escape". +

+
+ +
Discussion :
+
Cette technique fonctionne bien entendu pour tout autre + caractère spécial que mod_rewrite, par défaut, code pour insertion + dans une URL.
+
+ +
+ +
+ + Réécriture dépendant de l'heure + +
+
Description :
+ +
+

Nous voulons servir des contenus différents selon l'heure du + jour en utilisant mod_rewrite.

+
+ +
Solution :
+ +
+

Il existe de nombreuses variables nommées + TIME_xxx utilisables dans les conditions de + réécriture. Utilisées en conjonction avec les modèles de + comparaison lexicographique spéciaux <STRING, + >STRING et =STRING, elles + permettent d'effectuer des redirections dépendant de + l'heure :

+ + +RewriteEngine on
+RewriteCond %{TIME_HOUR}%{TIME_MIN} >0700
+RewriteCond %{TIME_HOUR}%{TIME_MIN} <1900
+RewriteRule ^foo\.html$ foo.jour.html [L]
+RewriteRule ^foo\.html$ foo.nuit.html +
+ +

Avec cet exemple, l'URL foo.html renvoie + le contenu de foo.jour.html durant le + créneau horaire 07:01-18:59, et le contenu de + foo.nuit.html le reste du temps.

+ + mod_cache, les mandataires + intermédiaires et les navigateurs peuvent chacun mettre en cache + les réponses et ainsi afficher une des deux pages en dehors de + la fenêtre de temps configurée. On peut utiliser + mod_expires pour contourner ce problème. Il est + cependant bien plus commode de servir un contenu dynamique, et + de le personnaliser en fonction de l'heure du jour.
+
+ +
+ +
+ + Définir des variables d'environnement en fonction de + certaines parties de l'URL + +
+
Description :
+ +
+

Ici, nous voulons conserver une certaine forme de statut + lorsqu'une réécriture a eu lieu. Par exemple, vous souhaitez + consigner le fait que cette réécriture a eu lieu, et vous servir + plus tard de cette information pour déterminer si une requête sera + concernée par cette réécriture. Pour y parvenir, on peut utiliser + une variable d'environnement.

+
+ +
Solution :
+ +
+

Utiliser le drapeau [E] pour définir une variable + d'environnement.

+ + +RewriteEngine on
+RewriteRule ^/cheval/(.*) /poney/$1 [E=rewritten:1] +
+ +

Plus loin dans votre jeu de règles, vous pouvez vérifier le + contenu de cette variable d'environnement via une directive + RewriteCond :

+ + +RewriteCond %{ENV:rewritten} =1 + + +
+
+ +
+ +
diff --git a/docs/manual/rewrite/advanced.xml.meta b/docs/manual/rewrite/advanced.xml.meta index dbee8d81a5..98192e7018 100644 --- a/docs/manual/rewrite/advanced.xml.meta +++ b/docs/manual/rewrite/advanced.xml.meta @@ -8,5 +8,6 @@ en + fr diff --git a/docs/manual/rewrite/avoid.html b/docs/manual/rewrite/avoid.html index c45209be5b..f61e85a37e 100644 --- a/docs/manual/rewrite/avoid.html +++ b/docs/manual/rewrite/avoid.html @@ -3,3 +3,7 @@ URI: avoid.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 + +URI: avoid.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/rewrite/avoid.html.fr b/docs/manual/rewrite/avoid.html.fr new file mode 100644 index 0000000000..7e18617fe8 --- /dev/null +++ b/docs/manual/rewrite/avoid.html.fr @@ -0,0 +1,246 @@ + + + +Quand ne pas utiliser mod_rewrite - Serveur Apache HTTP + + + + + +
<-
+
+Apache > Serveur HTTP > Documentation > Version 2.4 > Rewrite

Quand ne pas utiliser mod_rewrite

+
+

Langues Disponibles:  en  | + fr 

+
+ + +

Ce document est un complément à la Documentation de référence de +mod_rewrite. Il décrit peut-être un des concepts les +plus importants à propos de mod_rewrite - à savoir, quand doit-on éviter +de l'utiliser.

+ +

mod_rewrite doit être considéré comme un dernier recours, +lorsqu'aucune alternative n'est possible. Utiliser mod_rewrite lorsqu'il +existe des alternatives plus simples conduit à des configurations +confuses, fragiles, et difficiles à maintenir. La compréhension des +autres alternatives disponibles est une étape très importante sur le +chemin de la maîtrise de mod_rewrite.

+ +

Vous devez vous attacher à comprendre le +fonctionnement des exemples, car la plupart d'entre eux ne +fonctionneront pas sur votre système si vous vous contentez de les +copier/coller dans vos fichiers de configuration.

+ +

Le cas le plus courant dans lequel mod_rewrite est +l'outil approprié est la situation où la seule solution envisageable +nécessite l'accès aux fichiers de configuration du serveur, alors que +cet accès ne vous est pas accordé. Certaines directives de configuration +ne sont disponibles que dans le fichier de configuration du serveur. Si +vous ne pouvez agir que sur les fichiers .htaccess, vous devrez donc +vous tourner vers mod_rewrite.

+ +
+ +
top
+
+

Redirection simple

+ + +

mod_alias fournit les directives Redirect et RedirectMatch qui permettent de +rediriger une URL vers une autre. Plutôt que d'utiliser la directive +RewriteRule pour ce genre de +redirection simple d'une URL ou d'une classe d'URLs vers une autre, on +préfèrera l'utilisation de ces directives. En outre, avec +RedirectMatch, vous pouvez inclure une expression +rationnelle dans votre critère de redirection, ce qui vous permet de +bénéficier de nombreux avantages de la directive +RewriteRule.

+ +

Une utilisation courante de la directive RewriteRule est +la redirection de toute une classe d'URLs. Par exemple, toutes les URLs +faisant référence au répertoire /un doivent être +redirigées vers http://un.example.com/, ou toutes les +requêtes http doivent être redirigées vers +https.

+ +

Pour ce faire, il est préférable d'utiliser la directive +Redirect. Souvenez-vous que la directive +Redirect conserve les informations relatives au chemin. En +d'autres termes, la redirection d'une URL /un va aussi +rediriger toutes les URLs de niveaux inférieurs comme +/un/deux.html et /un/trois/quatre.html.

+ +

Pour rediriger les URLs sous /un vers +http://un.example.com/, utilisez cette définition :

+ +

+Redirect /un/ http://un.example.com/ +

+ +

Pour rediriger les URLs http vers https, +utilisez cette définition :

+ +

+<VirtualHost *:80> +ServerName www.example.com
+Redirect / https://www.example.com/
+</VirtualHost > +
+<VirtualHost *:443> +ServerName www.example.com
+
+# ... insérer ici la configuration SSL
+</VirtualHost > +

+ +

L'utilisation de la directive RewriteRule pour accomplir +cette tâche peut se justifier s'il existe d'autres directives +RewriteRule dans la même portée. En effet, lorsque des +directives Redirect et RewriteRule se trouvent +dans la même portée, les directives RewriteRule sont +exécutées en premier, sans tenir compte de leur ordre d'apparition dans +le fichier de configuration.

+ +

Dans le cas de la redirection http-vers-https, l'utilisation +de règles RewriteRule se justifie si vous n'avez pas accès +au fichier de configuration principal, et devez donc accomplir cette +tâche au sein d'un fichier .htaccess.

+ +
top
+
+

Alias d'URL

+

La directive Alias permet +de mettre en correspondance un URI avec un répertoire, ce dernier étant +en général situé en dehors de l'arborescence définie par la directive +DocumentRoot. Bien qu'il soit +possible d'effectuer cette mise en correspondance avec +mod_rewrite, il est préférable d'utiliser la directive +Alias pour des raisons de simplicité et de performances.

+ +

Utilisation de la directive Alias

+Alias /chats /var/www/virtualhosts/felin/htdocs +

+ +

+Pour effectuer cette mise en correspondance, mod_rewrite +s'impose si vous n'avez pas accès aux fichiers de configuration du +serveur. En effet, la directive Alias ne peut pas être utilisée dans un +fichier .htaccess, mais seulement dans un contexte de +serveur principal ou de serveur virtuel. +

+ +

En outre, vous pouvez arriver au même résultat avec les liens +symboliques, pourvu que Options FollowSymLinks soit activé +sur votre serveur.

+
top
+
+

Hébergement virtuel

+

Bien qu'il soit possible de gérer les serveurs +virtuels avec mod_rewrite, il s'agit rarement de la bonne méthode. +Il est pratiquement toujours préférable de créer des blocs +<VirtualHost> individuels. Dans l'éventualité où vous devez gérer +un grand nombre de serveurs virtuels, vous devez vous tourner vers +mod_vhost_alias pour créer ces serveurs +automatiquement.

+ +

Il est aussi possible d'utiliser des modules tiers comme mod_macro pour +créer un grand nombre de serveurs virtuels dynamiquement.

+ +

L'utilisation de mod_rewrite pour la création de +serveurs virtuels peut se révéler appropriée si votre service +d'hébergement ne vous permet pas d'accéder aux fichiers de configuration +du serveur, et que vous vous trouvez par conséquent obligé de passer par les +fichiers .htaccess.

+ +

Voir le document création de serveurs virtuels +avec mod_rewrite pour plus de détails sur la manière d'y parvenir si +cela semble être tout de même la meilleure approche.

+ +
top
+
+

Mandat simple

+ +

La directive RewriteRule fournit le drapeau [P] qui permet de faire passer les URIs +réécrits par mod_proxy.

+ +

+RewriteRule ^/?images(.*) http://serveur-images.local/images$1 [P] +

+ +

Cependant, dans les nombreux cas où aucune correspondance au modèle +n'est vraiment nécessaire, comme dans l'exemple ci-dessus, il est +préférable d'utiliser la directive ProxyPass. L'exemple précédent pourrait +être remplacé par :

+ +

+ProxyPass /images/ http://serveur-images.local/images/ +

+ +

Que vous utilisiez RewriteRule ou ProxyPass, vous devrez dans tous les cas +utiliser aussi la directive ProxyPassReverse pour intercepter les +redirections en provenance du serveur d'arrière-plan :

+ +

+ProxyPassReverse /images/ http://serveur-images.local/images/ +

+ +

Vous devrez cependant tout de même utiliser RewriteRule +lorsque d'autres RewriteRules se trouvent dans la même portée, +car elles agissent en général avant les directives +ProxyPass, et peuvent ainsi les court-circuiter.

+ +
top
+
+

Test de variables d'environnement

+ +

mod_rewrite est souvent utilisé pour effectuer une +action en fonction de la présence ou de l'absence d'une variable +d'environnement particulière ou d'un en-tête de requête, ce qui peut +être accompli de manière plus efficace via la directive <If>.

+ +

Considérons par exemple le scénario courant où la directive +RewriteRule est utilisée pour forcer un nom +d'hôte canonique, tel que www.example.com au lieu de +example.com. Il est possible d'utiliser à la place la +directive <If> comme +suit :

+ +

+<If "$req{Host} != 'www.example.com'">
+RedirectMatch (.*) http://www.example.com$1
+</If> +

+ +

On peut utiliser cette technique dans de nombreux scénarios courants +en remplacement de mod_rewrite pour effectuer des actions +en fonction d'en-têtes de requêtes ou de réponses, ou de variables +d'environnement.

+ +

Voir en particulier la documentation sur +l'évaluation des expressions pour une vue d'ensemble des types +d'expressions que vous pouvez utiliser dans les sections <If>, +ainsi que dans certaines directives.

+ +
+
+

Langues Disponibles:  en  | + fr 

+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/avoid.xml.fr b/docs/manual/rewrite/avoid.xml.fr new file mode 100644 index 0000000000..d1c1699167 --- /dev/null +++ b/docs/manual/rewrite/avoid.xml.fr @@ -0,0 +1,260 @@ + + + + + + + + + + + Rewrite + +Quand ne pas utiliser mod_rewrite + + + +

Ce document est un complément à la Documentation de référence de +mod_rewrite. Il décrit peut-être un des concepts les +plus importants à propos de mod_rewrite - à savoir, quand doit-on éviter +de l'utiliser.

+ +

mod_rewrite doit être considéré comme un dernier recours, +lorsqu'aucune alternative n'est possible. Utiliser mod_rewrite lorsqu'il +existe des alternatives plus simples conduit à des configurations +confuses, fragiles, et difficiles à maintenir. La compréhension des +autres alternatives disponibles est une étape très importante sur le +chemin de la maîtrise de mod_rewrite.

+ +

Vous devez vous attacher à comprendre le +fonctionnement des exemples, car la plupart d'entre eux ne +fonctionneront pas sur votre système si vous vous contentez de les +copier/coller dans vos fichiers de configuration.

+ +

Le cas le plus courant dans lequel mod_rewrite est +l'outil approprié est la situation où la seule solution envisageable +nécessite l'accès aux fichiers de configuration du serveur, alors que +cet accès ne vous est pas accordé. Certaines directives de configuration +ne sont disponibles que dans le fichier de configuration du serveur. Si +vous ne pouvez agir que sur les fichiers .htaccess, vous devrez donc +vous tourner vers mod_rewrite.

+ +
+Documentation du module mod_rewrite +Introduction à mod_rewrite +Redirection et remise en +correspondance +Contrôle d'accès +Serveurs virtuels +Serveurs mandataires +Utilisation de RewriteMap +Techniques avancées + + +
+Redirection simple + +

mod_alias fournit les directives Redirect et RedirectMatch qui permettent de +rediriger une URL vers une autre. Plutôt que d'utiliser la directive +RewriteRule pour ce genre de +redirection simple d'une URL ou d'une classe d'URLs vers une autre, on +préfèrera l'utilisation de ces directives. En outre, avec +RedirectMatch, vous pouvez inclure une expression +rationnelle dans votre critère de redirection, ce qui vous permet de +bénéficier de nombreux avantages de la directive +RewriteRule.

+ +

Une utilisation courante de la directive RewriteRule est +la redirection de toute une classe d'URLs. Par exemple, toutes les URLs +faisant référence au répertoire /un doivent être +redirigées vers http://un.example.com/, ou toutes les +requêtes http doivent être redirigées vers +https.

+ +

Pour ce faire, il est préférable d'utiliser la directive +Redirect. Souvenez-vous que la directive +Redirect conserve les informations relatives au chemin. En +d'autres termes, la redirection d'une URL /un va aussi +rediriger toutes les URLs de niveaux inférieurs comme +/un/deux.html et /un/trois/quatre.html.

+ +

Pour rediriger les URLs sous /un vers +http://un.example.com/, utilisez cette définition :

+ + +Redirect /un/ http://un.example.com/ + + +

Pour rediriger les URLs http vers https, +utilisez cette définition :

+ + +<VirtualHost *:80> +ServerName www.example.com
+Redirect / https://www.example.com/
+</VirtualHost > +
+<VirtualHost *:443> +ServerName www.example.com
+
+# ... insérer ici la configuration SSL
+</VirtualHost > +
+ +

L'utilisation de la directive RewriteRule pour accomplir +cette tâche peut se justifier s'il existe d'autres directives +RewriteRule dans la même portée. En effet, lorsque des +directives Redirect et RewriteRule se trouvent +dans la même portée, les directives RewriteRule sont +exécutées en premier, sans tenir compte de leur ordre d'apparition dans +le fichier de configuration.

+ +

Dans le cas de la redirection http-vers-https, l'utilisation +de règles RewriteRule se justifie si vous n'avez pas accès +au fichier de configuration principal, et devez donc accomplir cette +tâche au sein d'un fichier .htaccess.

+ +
+ +
Alias d'URL +

La directive Alias permet +de mettre en correspondance un URI avec un répertoire, ce dernier étant +en général situé en dehors de l'arborescence définie par la directive +DocumentRoot. Bien qu'il soit +possible d'effectuer cette mise en correspondance avec +mod_rewrite, il est préférable d'utiliser la directive +Alias pour des raisons de simplicité et de performances.

+ +Utilisation de la directive Alias +Alias /chats /var/www/virtualhosts/felin/htdocs + + +

+Pour effectuer cette mise en correspondance, mod_rewrite +s'impose si vous n'avez pas accès aux fichiers de configuration du +serveur. En effet, la directive Alias ne peut pas être utilisée dans un +fichier .htaccess, mais seulement dans un contexte de +serveur principal ou de serveur virtuel. +

+ +

En outre, vous pouvez arriver au même résultat avec les liens +symboliques, pourvu que Options FollowSymLinks soit activé +sur votre serveur.

+
+ +
Hébergement virtuel +

Bien qu'il soit possible de gérer les serveurs +virtuels avec mod_rewrite, il s'agit rarement de la bonne méthode. +Il est pratiquement toujours préférable de créer des blocs +<VirtualHost> individuels. Dans l'éventualité où vous devez gérer +un grand nombre de serveurs virtuels, vous devez vous tourner vers +mod_vhost_alias pour créer ces serveurs +automatiquement.

+ +

Il est aussi possible d'utiliser des modules tiers comme mod_macro pour +créer un grand nombre de serveurs virtuels dynamiquement.

+ +

L'utilisation de mod_rewrite pour la création de +serveurs virtuels peut se révéler appropriée si votre service +d'hébergement ne vous permet pas d'accéder aux fichiers de configuration +du serveur, et que vous vous trouvez par conséquent obligé de passer par les +fichiers .htaccess.

+ +

Voir le document création de serveurs virtuels +avec mod_rewrite pour plus de détails sur la manière d'y parvenir si +cela semble être tout de même la meilleure approche.

+ +
+ +
Mandat simple + +

La directive RewriteRule fournit le drapeau [P] qui permet de faire passer les URIs +réécrits par mod_proxy.

+ + +RewriteRule ^/?images(.*) http://serveur-images.local/images$1 [P] + + +

Cependant, dans les nombreux cas où aucune correspondance au modèle +n'est vraiment nécessaire, comme dans l'exemple ci-dessus, il est +préférable d'utiliser la directive ProxyPass. L'exemple précédent pourrait +être remplacé par :

+ + +ProxyPass /images/ http://serveur-images.local/images/ + + +

Que vous utilisiez RewriteRule ou ProxyPass, vous devrez dans tous les cas +utiliser aussi la directive ProxyPassReverse pour intercepter les +redirections en provenance du serveur d'arrière-plan :

+ + +ProxyPassReverse /images/ http://serveur-images.local/images/ + + +

Vous devrez cependant tout de même utiliser RewriteRule +lorsque d'autres RewriteRules se trouvent dans la même portée, +car elles agissent en général avant les directives +ProxyPass, et peuvent ainsi les court-circuiter.

+ +
+ +
Test de variables d'environnement + +

mod_rewrite est souvent utilisé pour effectuer une +action en fonction de la présence ou de l'absence d'une variable +d'environnement particulière ou d'un en-tête de requête, ce qui peut +être accompli de manière plus efficace via la directive If.

+ +

Considérons par exemple le scénario courant où la directive +RewriteRule est utilisée pour forcer un nom +d'hôte canonique, tel que www.example.com au lieu de +example.com. Il est possible d'utiliser à la place la +directive If comme +suit :

+ + +<If "$req{Host} != 'www.example.com'">
+RedirectMatch (.*) http://www.example.com$1
+</If> +
+ +

On peut utiliser cette technique dans de nombreux scénarios courants +en remplacement de mod_rewrite pour effectuer des actions +en fonction d'en-têtes de requêtes ou de réponses, ou de variables +d'environnement.

+ +

Voir en particulier la documentation sur +l'évaluation des expressions pour une vue d'ensemble des types +d'expressions que vous pouvez utiliser dans les sections <If>, +ainsi que dans certaines directives.

+ +
+ +
+ diff --git a/docs/manual/rewrite/avoid.xml.meta b/docs/manual/rewrite/avoid.xml.meta index c734d099c0..9d51904e7b 100644 --- a/docs/manual/rewrite/avoid.xml.meta +++ b/docs/manual/rewrite/avoid.xml.meta @@ -8,5 +8,6 @@ en + fr diff --git a/docs/manual/rewrite/htaccess.html b/docs/manual/rewrite/htaccess.html index 491a51c7ab..6f35b58bae 100644 --- a/docs/manual/rewrite/htaccess.html +++ b/docs/manual/rewrite/htaccess.html @@ -3,3 +3,7 @@ URI: htaccess.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 + +URI: htaccess.html.fr +Content-Language: fr +Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/rewrite/htaccess.html.fr b/docs/manual/rewrite/htaccess.html.fr new file mode 100644 index 0000000000..d42806203c --- /dev/null +++ b/docs/manual/rewrite/htaccess.html.fr @@ -0,0 +1,41 @@ + + + +mod_rewrite et les fichiers .htaccess - Serveur Apache HTTP + + + + + +
<-
+
+Apache > Serveur HTTP > Documentation > Version 2.4 > Rewrite

mod_rewrite et les fichiers .htaccess

+
+

Langues Disponibles:  en  | + fr 

+
+ + +

Ce document est un complément de la documentation de référence du module +mod_rewrite. Il décrit les changements apportés aux règles +lorsqu'on utilise mod_rewrite dans les fichiers .htaccess, et comment +travailler avec ces changements.

+ +
+ +
+
+

Langues Disponibles:  en  | + fr 

+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/htaccess.xml.fr b/docs/manual/rewrite/htaccess.xml.fr new file mode 100644 index 0000000000..c90d966fe7 --- /dev/null +++ b/docs/manual/rewrite/htaccess.xml.fr @@ -0,0 +1,50 @@ + + + + + + + + + + + Rewrite + +mod_rewrite et les fichiers .htaccess + + + +

Ce document est un complément de la documentation de référence du module +mod_rewrite. Il décrit les changements apportés aux règles +lorsqu'on utilise mod_rewrite dans les fichiers .htaccess, et comment +travailler avec ces changements.

+ +
+Documentation du module mod_rewrite +Introduction à mod_rewrite +Redirection et remise en +correspondance + +Serveurs virtuels +Serveurs mandataires +Utilisation de RewriteMap +Techniques avancées +Quand ne pas utiliser mod_rewrite + +
diff --git a/docs/manual/rewrite/htaccess.xml.meta b/docs/manual/rewrite/htaccess.xml.meta index dfb5bbd550..00ee9a1c1e 100644 --- a/docs/manual/rewrite/htaccess.xml.meta +++ b/docs/manual/rewrite/htaccess.xml.meta @@ -8,5 +8,6 @@ en + fr