From: Lucien Gentis Date: Thu, 2 Jul 2026 16:01:29 +0000 (+0000) Subject: fr doc XML file update. X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=1b5d90708dbbb94620035f72878adb6022e8df37;p=thirdparty%2Fapache%2Fhttpd.git fr doc XML file update. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1935810 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/rewrite/avoid.xml.fr b/docs/manual/rewrite/avoid.xml.fr index 995159d0d2..ef5b509630 100644 --- a/docs/manual/rewrite/avoid.xml.fr +++ b/docs/manual/rewrite/avoid.xml.fr @@ -1,7 +1,7 @@ - + @@ -60,12 +60,11 @@ vous tourner vers mod_rewrite.

Introduction à mod_rewrite Redirection et remise en correspondance -Contrôle d'accès +Réécritures par répertoire +Drapeaux de RewriteRule Serveurs virtuels -Serveurs mandataires Utilisation de RewriteMap -Techniques avancées - +Détails techniques
Redirection simple @@ -107,45 +106,36 @@ Redirect "/one/" "http://one.example.com/" example.com vers www.example.com, voir la méthode Noms d'hôtes canoniques.

-

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.

+

Pour rediriger les URLs http vers https, une +directive Redirect dans un serveur +virtuel HTTP dédié est l’approche la plus propre. Voir la recette Forcer HTTPS pour la configuration +recommandée et l’alternative de mod_rewrite pour l’utilisation +des fichiers .htaccess.

+ + Ordre de traitement +

Si vous mélangez des directives Redirect et RewriteRule dans le même contexte, sachez + que leur ordre d’exécution dépend de l’emplacement où elles apparaissent. + Dans un contexte de serveur virtuel ou global, c’est + mod_rewrite qui agit en premier, alors que dans un contexte + de répertoire (fichiers .htaccess), c’est + mod_alias. Voir Ordre de + traitement des modules pour les détails.

+
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.

+

La directive Alias permet de mettre +en correspondance un chemin d’URL 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 @@ -166,31 +156,6 @@ 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 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 soyez 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 @@ -228,6 +193,25 @@ 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.

+

RewriteRule s’avère vraiment +utile pour ne mandater les requêtes que si le contenu n’existe pas localement +— par exemple, lors de la migration d’un serveur vers un autre :

+ + +RewriteCond "%{REQUEST_FILENAME}" !-f +RewriteCond "%{REQUEST_FILENAME}" !-d +RewriteRule "^/(.*)" "http://old.example.com/$1" [P] +ProxyPassReverse "/" "http://old.example.com/" + + +

Dans cet exemple, les requêtes pour des ressources qui n’ont pas encore été +migrées sont mandatées silencieusement vers l’ancien serveur. Lors de la +migration du contenu, les fichiers locaux ont la priorité. N’oubliez pas de +toujours inclure une directive ProxyPassReverse pour être sûr que toute +redirection effectuée par le serveur dorsal est correctement transmise au +client.

+
Test de variables d'environnement @@ -264,4 +248,343 @@ ainsi que dans certaines directives.

+
Contrôleur frontal / Routage des +ressources + +

Une utilisation très courante de mod_rewrite consiste à +router toutes les requêtes pour des ressources non existantes vers un seul +script de contrôle frontal (par exemple index.php). Il s’agit de la +base du routage dans le cadre de la plus grande partie du web moderne.

+ +

L’approche typique avec mod_rewrite est :

+ + +RewriteEngine On +RewriteCond "%{REQUEST_FILENAME}" !-f +RewriteCond "%{REQUEST_FILENAME}" !-d +RewriteRule "^(.*)$" "/index.php" [L] + + +

Cette opération peut être effectuée beaucoup plus simplement avec la +directive FallbackResource :

+ + +FallbackResource /index.php + + +

La directive FallbackResource fait la +même chose — les requêtes pour des fichiers et répertoires existants sont +traitées normalement, toutes les autres étant routées vers la ressource +spécifiée — mais sans la surcharge de travail et la complexité du moteur de +réécriture. Elle fonctionne dans les deux contextes de configuration globale du +serveur et des fichiers .htaccess.

+ +

Pour désactiver une FallbackResource définie dans un répertoire +parent :

+ + +FallbackResource disabled + + +
+ +
Configuration conditionnelle avec des +expressions rationnelles + +

Dans de nombreux cas, l’utilisation de RewriteCond peut être remplacée par la +directive If qui prend en +charge une syntaxe des expressions riche et s’intègre +parfaitement avec les autres directives de httpd.

+ +

Redirection basée sur un élément de la chaîne de paramètres :

+ + +<If "%{QUERY_STRING} =~ /lang=fr/"> + Redirect "/welcome" "/bienvenue" +</If> + + +

Restriction d’accès en fonction de la méthode de la requête :

+ + +<If "%{REQUEST_METHOD} IN {'DELETE', 'PUT', 'PATCH'}"> + Require ip 10.0.0.0/8 +</If> + + +

Blocage des requêtes qui ne comportent pas d’en-tête Host (clients +HTTP/1.0) :

+ + +<If "-z req('Host')"> + Require all denied +</If> + + +

Voir la documentation sur l’évaluation des +expressions pour une description complète de la syntaxe disponible dans les +blocs If.

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

Le référencement à chaud consiste pour les autres sites à inclure + directement vos images dans leurs pages en utilisant votre bande + passante pour servir des contenus pour le site de quelqu'un d'autre. + Vous pouvez empêcher cela sans utiliser + mod_rewrite.

+
+ +
Solution :
+ +
+

Utilisez la directive SetEnvIf avec la directive Require :

+ + +SetEnvIf Referer example\.com localreferer +<FilesMatch "\.(jpg|png|gif)$"> + Require env localreferer +</FilesMatch> + +
+ +
Discussion :
+ +
+

Si vous avez besoin d’une logique plus complexe — comme servir une + autre image aux référenceurs à chaud au lieu de rejeter la requête — vous + aurez peut-être besoin de mod_rewrite. Les exemples + suivants s’appuient sur l’en-tête HTTP_REFERER qui est + facultatif et peut être usurpé. La condition !^$ autorise les + requêtes qui ne comportent aucun en-tête Referer, de sorte que les + utilisateurs qui saisissent l’URL directement, ou dont les navigateurs + suppriment cet en-tête ne soient pas bloqués.

+ +

Rejeter purement et simplement la requête :

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

Servir une image alternative :

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

Vous voulez bloquer les requêtes persistantes d’un robot particulier ou + d’un agent utilisateur qui ignore votre /robots.txt.

+
+ +
Solution :
+ +
+

Utilisez la directive SetEnvIfNoCase avec la directive + Require :

+ + +SetEnvIfNoCase User-Agent ^NameOfBadRobot goaway +<Location "/secret/files"> + <RequireAll> + Require all granted + Require not env goaway + </RequireAll> +</Location> + +
+ +
Discussion :
+ +
+

Toute technique qui s’appuie sur la chaîne USER_AGENT peut + être facilement contournée, car cette chaîne peut être modifiée par le + client. Si vous subissez une attaque soutenue, vous devez la traiter à un + niveau supérieur, par exemple au niveau de votre pare-feu.

+ +

Si vous devez combiner la recherche de correspondance par agent + utilisateur et par adresse IP, mod_rewrite peut être + utilisé en remplacement :

+ + +RewriteCond "%{HTTP_USER_AGENT}" "^NameOfBadRobot" +RewriteCond "%{REMOTE_ADDR}" "=123\.45\.67\.[8-9]" +RewriteRule "^/secret/files/" "-" [F] + + +
+
+ +
+ +
+ + Interdire des hôtes dans une liste de rejets + +
+
Description :
+ +
+

Nous souhaitons établir une liste des hôtes auxquels nous voulons + interdire l’accès à notre serveur.

+
+ +
Solution :
+ +
+

Pour un simple blocage basé sur l’adresse IP, utilisez la directive + Require directement :

+ + +<Location "/"> + Require all granted + Require not ip 193.102.180.41 + Require not ip 192.76.162.40 +</Location> + +
+ +
Discussion :
+ +
+

Si vous avez besoin d’une liste d’interdiction dynamique basée sur un + fichier (plutôt que d’énumérer des adresses IP dans la configuration), + vous pouvez utiliser mod_rewrite et sa directive + RewriteMap :

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

Le fichier de mappage contient une entrée par ligne, avec une adresse + IP ou un nom d’hôte comme clé et une valeur factice (parce que la + directive RewriteMap requiert + des paires clé/valeur) :

+ + +## hosts.deny
+193.102.180.41 -
+192.76.162.40 -
+ + +

La seconde directive RewriteCond présuppose que + HostnameLookups est activé. Dans le cas contraire, + supprimer-la, ainsi que le drapeau [OR] de la première + condition.

+
+
+ +
+ +
Serveurs virtuels +

Bien qu’il soit possible de gérer les serveurs virtuels +avec mod_rewrite, il s’agit rarement de la bonne méthode. Le bon choix +consiste pratiquement toujours à créer des blocs VirtualHost individuels. Si vous devez gérer un très +grand nombre de serveurs virtuels, choisissez plutôt d’utiliser +mod_vhost_alias pour créer ces hôtes automatiquement.

+ +

Des modules tels que mod_macro permettent aussi de créer un +grand nombre de serveurs virtuels dynamiquement.

+ +

Utiliser mod_rewrite pour la création de serveurs virtuels +peut convenir si vous utilisez un service d’hébergement qui ne vous permet pas +d’accéder aux fichiers de configuration du serveur, et que vous soyez par +conséquent contraint d’utiliser des fichiers .htaccess.

+ +

Voir le document les serveurs virtuels avec +mod_rewrite pour plus de détails sur la manière de procéder si cette +approche vous semble encore être la bonne.

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

Nous souhaitons répartir la charge entre plusieurs serveurs dorsaux.

+
+ +
Solution :
+ +
+

Utilisez le module mod_proxy_balancer qui fournit une + solution de répartition de charge flexible et totalement fonctionnelle. Il + prend en charge plusieurs algorithmes de répartition, la persistance de + session, les contrôles de bon fonctionnement et une configuration + dynamique avec le gestionnaire de répartition de charge (Balancer Manager) + — toutes choses impossibles avec l’approche de + mod_rewrite.

+ + +<Proxy "balancer://mycluster"> + BalancerMember "http://one.example.com" + BalancerMember "http://two.example.com" + BalancerMember "http://three.example.com" +</Proxy> +ProxyPass "/" "balancer://mycluster/" +ProxyPassReverse "/" "balancer://mycluster/" + + +
+ +
Discussion :
+
+ +

Il est possible de mettre en œuvre une répartition de charge aléatoire +rudimentaire en utilisant mod_rewrite et une directive +RewriteMap de type +rnd :

+ + +RewriteEngine on +RewriteMap lb "rnd:/path/to/serverlist.txt" +RewriteRule "^/(.*)" "http://${lb:servers}/$1" [P,L] + + +

mod_proxy_balancer est cependant beaucoup plus flexible et +fonctionnel que tout ce que vous pourrez « bricoler » en utilisant +mod_rewrite, et correspond à l’approche recommandée.

+ +
+
+ +
+