From: Lucien Gentis Date: Fri, 10 Jul 2026 14:36:02 +0000 (+0000) Subject: fr doc XML file update. X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=ce0332191c7fd187475d5649dc97ba300d581b36;p=thirdparty%2Fapache%2Fhttpd.git fr doc XML file update. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1936042 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/rewrite/remapping.xml.fr b/docs/manual/rewrite/remapping.xml.fr index 61cc19590c..dac57b00f9 100644 --- a/docs/manual/rewrite/remapping.xml.fr +++ b/docs/manual/rewrite/remapping.xml.fr @@ -1,7 +1,7 @@ - + @@ -37,22 +37,15 @@ correspondance une requête. 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 - -Contrôler l'accès +Réécritures par répertoire +Drapeaux des règles RewriteRule Serveurs virtuels -Serveurs mandataires Utilisation de RewriteMap -Techniques avancées Quand ne pas utiliser mod_rewrite +Détails techniques
@@ -80,11 +73,239 @@ correspondance--> RewriteEngine on RewriteRule "^/foo\.html$" "/bar.html" [PT] + + + +
+ +
+ + Forcer HTTPS + +
+
Description :
+ +
+

Rediriger toutes les requêtes HTTP vers HTTPS. C’est un des + emplois les plus courants de mod_rewrite, mais dans la + plupart des cas, on y parvient d’une meilleur façon sans lui.

+
+ +
Solution :
+ +
+ +

L’approche préférée utilise une directive Redirect dans un serveur virtuel HTTP + dédié :

+ + +<VirtualHost *:80> + ServerName www.example.com + Redirect permanent "/" "https://www.example.com/" +</VirtualHost> + +<VirtualHost *:443> + ServerName www.example.com + # ... emplacement de la configuration SSL +</VirtualHost> + + +
+ +
Explication :
+ +
+

Si vous n’avez pas accès à la configuration du serveur et devez + utiliser un fichier .htaccess, mod_rewrite + sera l’outil approprié :

+ + +RewriteEngine On +RewriteCond "%{HTTPS}" !=on +RewriteRule "^(.*)" "https://%{SERVER_NAME}$1" [R=301,L] + + +

La variable %{HTTPS} est définie à on si + la connexion utilise SSL/TLS, et est vide ou à off dans le + cas contraire. Utiliser R=301 produit une redirection + permanente qui signale aux moteurs de recherche qu’ils doivent mettre + leur index à jour.

+ +

Voir aussi le document Quand ne pas + utiliser mod_rewrite pour plus de discussions à propos de l’approche + Redirect.

+ + Derrière un répartiteur de charge ou un terminateur SSL +

La variable %{HTTPS} n’est pas une variable + d’environnement à usage général — elle interroge directement + mod_ssl. Si la terminaison SSL/TLS est effectuée au + niveau d'un répartiteur de charge ou d'un mandataire inverse en amont, + mod_ssl ne gère pas la connexion et %{HTTPS} + indiquera toujours off, même si le client originel s’est + connecté en HTTPS.

+ +

Dans cette situation, il faut plutôt consulter l’en-tête défini par le + mandataire en amont. La plupart des répartiteurs de charge définissent + X-Forwarded-Proto :

+ + + +RewriteEngine On +RewriteCond "%{HTTP:X-Forwarded-Proto}" =http [NC] +RewriteRule "^(.*)" "https://%{SERVER_NAME}$1" [R=301,L] + + + +

Ne faites confiance à X-Forwarded-Proto que si vous + contrôlez le mandataire en amont et qu'il écrase l'en-tête à chaque + requête. Un attaquant pourrait corrompre cet en-tête en se connectant + directement à votre serveur. Assurez-vous de restreindre l’accès de façon + que seul votre répartiteur de charge puisse atteindre le serveur dorsal, + ou utilisez mod_remoteip pour valider la source.

+ +
+
+ + Exempter les requêtes de défi ACME de la redirection HTTPS + +
+
Description :
+ +
+

Vous avez forcé tout le trafic à s’effectuer en HTTPS (comme ci-avant), + mais votre client ACME (Let's Encrypt, Certbot, etc.) nécessite un accès + en HTTP à /.well-known/acme-challenge/ pour achever la + validation du domaine.

+
+ +
Solution :
+ +
+

Placer une exception avant la règle de redirection HTTPS :

+ + +RewriteEngine On +RewriteRule "^/\.well-known/acme-challenge/" - [L] +RewriteCond "%{HTTPS}" !=on +RewriteRule "^(.*)" "https://%{SERVER_NAME}$1" [R=301,L] + +
+ +
Explication :
+ +
+

La substitution matérialisée par un tiret (-) signifie + « ne pas réécrire ». En combinaison avec le drapeau [L], elle + arrête le traitement des règles pour toute requête correspondant au chemin + du défi ACME, permettant à cette dernière d’être servie en HTTP. Le + traitement de toutes les autres requêtes continue avec la règle suivante + et les redirige vers HTTPS de la manière habituelle.

+ +

Si vous adoptez l’approche par la directive Redirect dans un serveur virtuel dédié au + port 80, utilisez les directives Alias et RedirectMatch à la place :

+ + +<VirtualHost *:80> + ServerName www.example.com + + # Permettre les défis ACME sur HTTP + Alias "/.well-known/acme-challenge/" "/var/www/acme/.well-known/acme-challenge/" + <Directory "/var/www/acme/.well-known/acme-challenge"> + Require all granted + </Directory> + + # Tout le reste est redirigé vers HTTPS + RedirectMatch permanent "^/(?!\.well-known/acme-challenge/)(.*)$" "https://www.example.com/$1" +</VirtualHost> + + +
+
+ +
+ +
+ + Normalisation de la barre oblique de fin + +
+
Description :
+ +
+

Vous souhaitez que les URLs pour des répertoires se terminent toujours + par une barre oblique ou, au contraire, que ce ne soit jamais le cas. + Il s’agit d’un prérequis courant pour SEO et pour la gestion cohérente des + URLs par les applications web.

+
+ +
Solution :
+ +
+

Pour ajouter une barre oblique de fin aux URLs qui correspondent à des + répertoires :

+ + +RewriteCond "%{REQUEST_FILENAME}" -d +RewriteCond "%{REQUEST_URI}" "!/$" +RewriteRule "^(.*)$" "$1/" [R=301,L] + + +

Pour supprimer la barre oblique de fin (sauf pour les véritables + répertoires) :

+ + +RewriteCond "%{REQUEST_FILENAME}" !-d +RewriteCond "%{REQUEST_URI}" "(.+)/$" +RewriteRule "^" "%1" [R=301,L] + + +
+ +
Explication :
+ +
+

Le module mod_dir de httpd gère déjà les redirections + de barre oblique de fin pour les véritables répertoires lorsque la + directive DirectorySlash est + activée (elle l’est par défaut). Vous n’avez besoin que d’une règle de + mod_rewrite si vous souhaitez imposer un comportement + pour les barres obliques de fin pour les URLs qui ne correspondent pas à + de véritables répertoires sur disque, ou si vous voulez supprimer des + barres obliques de fin.

+
+
+ +
+ +
+ + Contrôleur frontal / Routage d’pplication + +

La plupart des cadriciels web modernes routent toutes les requêtes vers un + seul point d’entrée : le contrôleur frontal (« front controller »). La + directive FallbackResource gère cela + plus simplement et efficacement que mod_rewrite. Voir le + document Quand ne pas utiliser + mod_rewrite pour l’approche recommandée.

+ +

Si vous avez réellement besoin de mod_rewrite pour cela + (par exemple, pour ajouter des conditions plus complexes que « fichier non + existant »), consultez le document Réécritures par répertoire pour un + exemple annoté qui illustre aussi l’utilisation de la directive RewriteBase.

+ +
+
De l'ancien au nouveau (en externe) @@ -115,7 +336,7 @@ RewriteRule "^foo\.html$" "bar.html" [ -
Discussion
+
Explication

Dans l'exemple

- - -
- - - -
- - De statique à dynamique - -
-
Description :
- +
Explication :
-

Comment transformer une page statique foo.html - en sa variante dynamique foo.cgi de manière - transparente, c'est à dire sans en avertir le - navigateur/utilisateur.

-
-
Solution :
- -
-

On réécrit simplement l'URL en script CGI et force le - gestionnaire de contenu à cgi-script de façon - à ce que le script s'exécute en tant que programme CGI. - Ainsi, une requête vers /~quux/foo.html conduit - en interne à l'invocation de - /~quux/foo.cgi.

- - -RewriteEngine on -RewriteBase "/~quux/" -RewriteRule "^foo\.html$" "foo.cgi" [H=cgi-script] - +

Pour une simple redirection vers un autre serveur, il est préférable + d’utiliser les directives Redirect ou RedirectMatch, car elles sont plus simples + et plus efficaces.

@@ -224,10 +418,10 @@ RewriteRule "^foo\.html$" "foo.cgi" [H=cgi-script]
Solution :
-

L'URL n'est réécrite en remplaçant l'ancienne extension par la +

L’URL n’est réécrite en remplaçant l’ancienne extension par la nouvelle que si le fichier cible avec la nouvelle extension existe et - si le fichier originel avec l'ancienne extension n'existe pas. Sinon, - l'URL reste inchangée.

+ si le fichier originel avec l’ancienne extension n’existe pas. Sinon, + l’URL reste inchangée.

@@ -245,7 +439,7 @@ RewriteRule "^foo\.html$" "foo.cgi" [H=cgi-script]
-
Discussion
+
Explication

Cet exemple utilise une fonctionnalité souvent méconnue de mod_rewrite, en tirant avantage de l'ordre d'exécution du jeu de @@ -348,6 +542,16 @@ RewriteRule "^/?(.*)" "http://www.example.com/$1" [L,R,NE] possibles de example.com, vous pouvez utiliser le jeu de règles suivants :

+

Pour faire l’inverse — supprimer le préfixe www. — inversez la +condition :

+ + +RewriteCond "%{HTTP_HOST}" "^www\.(.+)$" [NC] +RewriteRule "^(.*)" "http://%1/$1" [L,R,NE] + + +

Pour ajouter de manière générique www. à tout nom d’hôte :

+ RewriteCond "%{HTTP_HOST}" "!^www\." [NC] RewriteCond "%{HTTP_HOST}" "!^$" @@ -359,9 +563,26 @@ RewriteRule "^/?(.*)" "http://www.%{HTTP_HOST}/$1" [L,R,NE] .htaccess placé dans le répertoire défini par la directive DocumentRoot du serveur.

-
- + + +
Explication :
+ +
+

Si vous avez accès à la configuration globale du serveur, une directive + Redirect dans un serveur virtuel dédié constitue + l’approche la plus propre. Mettre sous forme canonique le nom d’hôte + permet de s’assurer que les moteurs de recherche traiterons votre site + comme une seule entité, et évite les problèmes de portée de cookie qui + surviennent lorsqu’un même site est accessible sous plusieurs noms.

+

N’utilisez la directive If et mod_rewrite comme + compromis que si vous êtes contraint d’utiliser un fichier + .htaccess.

+
+ +
@@ -405,64 +626,14 @@ RewriteRule "^(.+)" "%{DOCUMENT_ROOT}/dir2/$1" [L] RewriteRule "^" "-" [PT] - - -
-
+
Explication :
- Redirection vers des serveurs géographiquement distribués - -
-
Description :
- -
-

Notre site web possède de nombreux miroirs, et nous voulons - rediriger les utilisateurs vers celui qui se situe dans le pays où - ils se trouvent.

-
- -
Solution :
- -
-

En consultant le nom d'hôte du client demandeur, on détermine le - pays dans lequel il se trouve. S'il est impossible d'effectuer une - recherche sur leur adresse IP, on se rabat sur un serveur par - défaut.

-

Nous allons utiliser une directive RewriteMap afin de construire une - liste des serveurs que nous voulons utiliser.

- - -HostnameLookups on -RewriteEngine on -RewriteMap multiplex "txt:/path/to/map.mirrors" -RewriteCond "%{REMOTE_HOST}" "([a-z]+)$ [NC]" -RewriteRule "^/(.*)$" "${multiplex:%1|http://www.example.com/}$1" [R,L] - - - -## liste_miroirs -- Table de correspondance pays - serveurs
-
-de http://www.exemple.de/
-uk http://www.exemple.uk/
-com http://www.example.com/
-##EOF## - -
- -
Discussion
- Ce jeu de règles nécessite la définition à - on de la directive HostNameLookups, ce qui peut induire une - baisse de performance significative. - -

La directive RewriteCond extrait la dernière - partie du nom d'hôte du client demandeur - le code du pays - et la - règle de réécriture qui suit utilise cette valeur pour rechercher le - serveur miroir approprié dans le fichier de correspondances.

+

Ce qui précède s’avère utile pendant les migrations lorsque le contenu + est déplacé d’un répertoire vers un autre. Pour une configuration + permanente, utilisez plutôt la directive Alias ou des liens symboliques.

@@ -555,56 +726,7 @@ de réécrire les URLs.

-
-Ressource par défaut - -
-
Description :
-
Vous voulez qu'une seule ressource (disons un certain fichier tel -que index.php) soit servie pour toutes les requêtes à destination d'un -certain répertoire, sauf pour celles qui concernent une ressource -existant effectivement comme une image, ou un fichier css.
- -
Solution :
-
-

Depuis la version 2.2.16, vous pouvez y parvenir via la directive -FallbackResource :

- - -<Directory "/var/www/my_blog"> - FallbackResource index.php -</Directory> - - -

Cependant, si vos besoins étaient plus complexes, vous pouviez, dans -les versions plus anciennes d'Apache, utiliser un jeu de règles du style -:

- - -<Directory "/var/www/my_blog"> - RewriteBase "/my_blog" - - RewriteCond "/var/www/my_blog/%{REQUEST_FILENAME}" !-f - RewriteCond "/var/www/my_blog/%{REQUEST_FILENAME}" !-d - RewriteRule "^" "index.php" [PT] -</Directory> - - -

D'autre part, si vous voulez transmettre l'URI de la requête en tant -que chaîne de paramètres à index.php, vous pouvez remplacer cette règle -de réécriture par :

-RewriteRule "(.*)" "index.php?$1" [PT,QSA] - -

Notez que l'on peut utiliser ces jeux de règles aussi bien dans un -fichier .htaccess que dans une section -<Directory>.

- -
- -
- -
Rewrite query string @@ -653,20 +775,208 @@ RewriteRule "(.*)" - [F] -
  • Cette solution produit l'effet inverse des précédentes ; elle - copie des composantes du chemin (peut-être PATH_INFO) depuis l'URL - vers sa chaîne de paramètres : - -# The desired URL might be /products/kitchen-sink, and the script expects +
  • Cette solution produit l'effet inverse des précédentes ; elle copie des + composantes du chemin (peut-être PATH_INFO) depuis l'URL vers sa chaîne de paramètres + : +# The desired URL might be /products/kitchen-sink, and the script expects # /path?products=kitchen-sink. -RewriteRule "^/?path/([^/]+)/([^/]+)" "/path?$1=$2" [PT] - +RewriteRule "^/?path/([^/]+)/([^/]+)" "/path?$1=$2" [PT]
    • +
    Explication :
    + +
    +

    Voir aussi les drapeaux [QSA] et [QSD] qui permettent de contrôler si la chaîne de +paramètres originelle est ajoutée à la fin de la substitution ou supprimée de +cette dernière.

    +
    + +
    +
    + + Répertoires utilisateur structurés + +
    +
    Description :
    + +
    +

    Certains sites avec plusieurs milliers d’utilisateurs possèdent une + organisation structurée des répertoires utilisateur, c’est-à-dire que + chaque répertoire utilisateur est dans un sous-répertoire qui commence + (par exemple) par le premier caractère du nom de l’utilisateur. Ainsi, + /~larry/anypath correspond à + /home/l/larry/public_html/anypath et + /~waldo/anypath à + /home/w/waldo/public_html/anypath.

    +
    + +
    Solution :
    + +
    +

    Nous utilisons le jeu de règles suivant pour développer les URLs avec + tilde selon l’organisation ci-dessus.

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

    Cette technique est principalement utile pour les environnements + d’hébergement de grande capacité avec plusieurs milliers d’utilisateurs. + Pour la plupart des sites, mod_userdir gère les URLs + utilisateur avec tilde sans avoir besoin de mod_rewrite.

    +
    +
    + +
    + +
    + + Redirection vers une ancre + +
    +
    Description :
    + +
    +

    Par défaut, la redirection vers une ancre HTML ne fonctionne pas, car + mod_rewrite échappe le caractère # en le + remplaçant par %23, ce qui casse la redirection.

    +
    + +
    Solution :
    + +
    +

    Utiliser le drapeau [NE] dans la règle + RewriteRule. NE signifie « No Escape ». +

    +
    + +
    Explication :
    +
    Bien entendu, cette technique fonctionne aussi pour d’autres caractères + spéciaux que mod_rewrite encode par défaut pour les URLs.
    +
    + +
    + +
    + + Réécriture dépendant du temps + +
    +
    Description :
    + +
    +

    Nous voulons utiliser mod_rewrite pour servir des + contenus différents en fonction de l’heure du jour.

    +
    + +
    Solution :
    + +
    +

    Il esixte de nombreuses variables nommées TIME_xxx à + utiliser dans les conditions de réécriture. En combinaison avec les motifs + de comparaison lexicographique spéciaux <STRING, + >STRING et =STRING, nous pouvons configurer + des redirections dépendant du temps :

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

    Cette configuration sert le contenu de foo.day.html sous + l’URL foo.html de 07:01 à 18:59 et + le contenu de foo.night.html pendant le temps restant.

    + + mod_cache, les mandataires + intermédiaires et les navigateurs peuvent chacun mettre en cache les + réponses et provoquer de ce fait l’affichage d’une page en dehors de la + fenêtre de temps configurée. mod_expires permet de + contrôler cet effet. Il est bien entendu préférable de simplement servir + le contenu de manière dynamique et de le personnaliser en fonction de + l’heure du jour. + +
    + +
    Explication :
    + +
    +

    Servir du contenu dynamique par l’intermédiaire de votre application + constitue pratiquement toujours une meilleure approche. La mise en cache + par les navigateurs, les mandataires et mod_cache rend la + réécriture en fonction du temps non fiable en pratique.

    +
    +
    + +
    + +
    + + Régénération du contenu à la volée + +
    +
    Description :
    + +
    +

    Nous voulons générer dynamiquement du contenu, mais le stocker ensuite + statiquement. La règle suivante va vérifier si le fichier + statique existe, et le générer dans le cas contraire. Les fichiers + statiques peuvent être supprimés périodiquement, si souhaité (par exemple + via cron) et seront régénérés à la demande.

    +
    + +
    Solution :
    + +
    + Pour ce faire, 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 détermine si la chaîne de test (dans ce cas + REQUEST_URI) est un URL valable. Il effectue cette opération + via une sous-requête. Si cette sous-requête échoue — autrement dit, si la + ressource demandée n’existe pas — cette règle invoque le programme CGI + /regenerate_page.cgi qui va générer la ressource demandée et la + sauvegarder dans le répertoire des documents de sorte qu’une copie statique + puissent en être servie la prochaine fois qu’elle sera demandée.

    + +

    Ainsi, les documents qui ne sont pas souvent mis à jour peuvent être + servis sous forme statique. Si ces documents doivent être rafraîchis, ils + peuvent être supprimés du répertoire des documents ; ils seront alors + régénérés la prochaine fois qu’ils seront demandés.

    +
    + +
    Explication :
    + +
    +

    Les approches modernes telles que mod_cache, les + couches de mise en cache CDN ou la mise en cache au niveau de + l’application fournissent des solutions plus robustes et configurables + pour servir du contenu statique pré-généré. Le test de la sous-requête de + l’opérateur -U utilisé ici induit un coût en performance à + chaque requête.

    +
    +
    + +
    +