From: Lucien Gentis Date: Wed, 8 Jul 2026 15:26:23 +0000 (+0000) Subject: fr doc XML files updates. X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=a655b3f59bd5cb7dca3648b1ab946ea724a45649;p=thirdparty%2Fapache%2Fhttpd.git fr doc XML files updates. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1936007 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/rewrite/rewritemap.xml.fr b/docs/manual/rewrite/rewritemap.xml.fr index c4ecb27c43..0a58ae7f6c 100644 --- a/docs/manual/rewrite/rewritemap.xml.fr +++ b/docs/manual/rewrite/rewritemap.xml.fr @@ -1,7 +1,7 @@ - + @@ -33,23 +33,16 @@ fournit des exemples pour chacun des différents types de RewriteMap.

- Notez que la plupart de ces exemples ne - fonctionneront pas en l'état dans le contexte de votre configuration - particulière ; vous devez donc vous attacher à les - comprendre, plutôt que de simplement les insérer dans votre - configuration par copier/coller. - - + Documentation du module mod_rewrite Introduction à mod_rewrite - Redirection et remise en - correspondance - Contrôle d'accès + Redirection et remise en correspondance + Drapeaux des règles de réécriture Serveurs virtuels - Mise en cache - Techniques avancées + Réécritures par répertoire Quand ne pas utiliser mod_rewrite + Détails techniques
Introduction @@ -154,7 +147,7 @@ exemples pour chacun d'entre eux.

module="mod_rewrite">RewriteRule :

-

Redirection d'un URI vers une version en minuscules +

Redirection d'un chemin d’URL vers une version en minuscules d'elle-même

@@ -413,7 +406,7 @@ directive RewriteMap.

directive Mutex.

Voici un exemple simple qui remplace tous les tirets par des - caractères de soulignement dans l'URI de la requête.

+ caractères de soulignement dans le chemin d’URL de la requête.

Configuration de la réécriture

@@ -431,16 +424,51 @@ for line in sys.stdin: print(line.strip().replace('-', '_'), flush=True) +

Un exemple plus complet montre un motif typique pour qu’un programme de + correspondance prg: lise une ligne, recherche le résultat et l’affiche. La + sortie de diagnostic est écrite sur STDERR et termine sa course + dans le journal des erreurs de httpd.

+ +

Configuration de la réécriture

+ +RewriteMap vhost2docroot "prg:/www/bin/vhost_lookup.py" +RewriteRule "^/(.*)$" "${vhost2docroot:%{HTTP_HOST}}/$1" + + +

vhost_lookup.py

+ +#!/usr/bin/env python3 +"""Associer un nom d’hôte au répertoire racine de ses documents.""" +import sys + +VHOSTS = { + "example.com": "/srv/www/example", + "blog.example.com": "/srv/www/blog", +} + +for line in sys.stdin: + host = line.strip().lower() + docroot = VHOSTS.get(host) + if docroot: + print(docroot, flush=True) + else: + # "NULL" indique à mod_rewrite que la recherche a échoué + print("NULL", flush=True) + print(f"vhost_lookup: no match for {host!r}", file=sys.stderr) + + Mises en garde !
    -
  • Votre programme doit être le plus -simple possible. Si le programme se bloque, httpd va attendre -indéfiniment une réponse de sa part, et par conséquent ne répondra plus -aux requêtes.
    • -
  • Assurez-vous de bien désactiver la mise en tampon dans votre -programme. Dans l'exemple en Python ci-avant, cette opération s'effectue en -passant flush=True à print(). Si les entrées/sorties sont mises en tampon, httpd va -attendre une sortie, et va par conséquent se bloquer.
    • +
  • Votre programme doit être le plus simple possible. Si le programme se +bloque, httpd va attendre indéfiniment une réponse de sa part, et par conséquent +ne répondra plus aux requêtes.
    • +
  • Assurez-vous de bien désactiver la mise en tampon dans votre programme. Dans +l'exemple en Python ci-avant, cette opération s'effectue en passant +flush=True à print(). Si les entrées/sorties sont +mises en tampon, httpd va attendre une sortie, et va par conséquent se bloquer. +Il s’agit de la cause la plus courante pour laquelle le mappage prg: semble ne +rien faire — le programme a la réponse mais httpd ne la verra jamais, car +elle est prisonnière d’un tampon.
  • Rappelez-vous qu'il n'existe qu'une copie du programme lancé au démarrage du serveur, et que toutes les requêtes vont devoir passer par ce goulot d'étranglement. Ceci peut provoquer des ralentissements @@ -494,6 +522,78 @@ RewriteMap ma-requete "fastdbd:SELECT destination FROM rewrite WHERE source = %s règles imposées par votre base de données (comme la sensibilité à la casse).

+ +
+ + Distribution de la charge (sharding) basée sur l'URL entre plusieurs serveurs dorsaux + +
+
Description :
+ +
+

Le « sharding » est une technique courante de distribution de la charge + de travail ou de l’espace de stockage. Lorsqu’on utilise cette méthode, un + serveur frontal va utiliser l’URL pour distribuer les utilisateurs ou + objets à des serveurs dorsaux de manière cohérente.

+
+ +
Solution :
+ +
+

Un mappage entre les utilisateurs et les serveurs cible est entretenu + dans des fichiers de mappage. Ces derniers sont sous la forme :

+ + +utilisateur1 serveur_physique_de_utilisateur1
+utilisateur2 serveur_physique_de_utilisateur2
+# ... et ainsi de suite + + +

Nous inscrivons ceci dans un fichier + mappage.utilisateur-vers-serveur. Le but est d’associer

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

à

+ + +http://serveur_physique_de_utilisateur1/u/utilisateur/chemin + + +

de sorte que tous les chemins d’URL n’ont pas besoin d’être valables + sur chaque serveur dorsal physique. Le jeu de règles suivant fait cela + pour nous avec l’aide des fichiers de mappage, en supposant que server0 + est un serveur par défaut qui sera utilisé si un utilisateur n’a pas + d’entrée dans le mappage :

+ + +RewriteEngine on +RewriteMap users-to-hosts "txt:/path/to/map.users-to-hosts" +RewriteRule "^/u/([^/]+)/?(.*)" "http://${users-to-hosts:$1|server0}/u/$1/$2" + +
+ +
Discussion :
+ +
+

Pour distribuer les requêtes aux différents serveurs dorsaux, + mod_proxy_balancer constitue une approche plus robuste et + configurable, avec la prise en charge d’un bilan de santé, d’une + pondération des charges et de la persistance des sessions. L’approche + basée sur un mappage txt: présentée ici est plus simple mais ne prend pas + en charge ces fonctionnalités.

+
+
+ +

Voir la documentation de RewriteMap pour une description plus complète + de la syntaxe de cette directive. +

+ +
+
Résumé diff --git a/docs/manual/rewrite/tech.xml.fr b/docs/manual/rewrite/tech.xml.fr index 8f1a8a759b..29bdcb743a 100644 --- a/docs/manual/rewrite/tech.xml.fr +++ b/docs/manual/rewrite/tech.xml.fr @@ -1,7 +1,7 @@ - + - + @@ -35,9 +35,10 @@ module mod_rewrite et de la mise en correspondance des URLs

Introduction à mod_rewrite Redirection et remise en correspondance +Drapeaux de réécriture Serveurs virtuels Utilisation de RewriteMap -Réécritures en fonction du répertoire (.htaccess) +Réécritures en fonction du répertoire Quand ne pas utiliser mod_rewrite
Phases de l'API @@ -63,7 +64,7 @@ correspondance

Lorsqu'une requête arrive et une fois le serveur correspondant ou le serveur virtuel déterminé, le moteur de - réécriture commence à traiter toute directive apparaissant dans la + réécriture commence à traiter toute directive mod_rewrite apparaissant dans la configuration de niveau serveur (autrement dit dans le fichier de configuration principal du serveur et les sections Virtualhost). @@ -76,109 +77,197 @@ correspondance type="section">Directory) sont appliquées. Ce processus s'exécute au cours de la phase Fixup.

-

Dans tous ces cas, mod_rewrite réécrit le - REQUEST_URI soit vers une nouvelle URL, soit vers un +

Dans tous ces cas, mod_rewrite réécrit le + REQUEST_URI soit vers un nouvel URL, soit vers un nom de fichier.

-

Dans un contexte de répertoire (autrement dit dans les - fichiers .htaccess et les sections - Directory), les règles de réécriture s'appliquent après - la traduction de l'URL en nom de fichier. C'est pourquoi le chemin - URL auquel mod_rewrite compare initialement les directives - RewriteRule est le - chemin complet vers le nom de fichier traduit amputé de la partie - répertoires (y compris le dernier slash).

- -

Un exemple : si les règles se trouvent dans - /var/www/foo/.htaccess et si une requête pour /foo/bar/baz est - traité, une expression comme ^bar/baz$ correspondra.

- -

Si une substitution intervient dans un contexte de répertoire, - une nouvelle sous-requête interne est générée avec la nouvelle URL, - ce qui relance le traitement des phases de la requête. Si la - substitution est un chemin relatif, la directive RewriteBase détermine le chemin URL - devant préfixer cette substitution. Dans un contexte de répertoire, - il faut s'assurer de créer des règles qui - n'effectueront pas de substitution au - cours d'une passe ultérieure du processus de réécriture au niveau - répertoire afin d'éviter les bouclages . Voir Bouclage dans le - processus de réécriture pour une discussion plus détaillée à - propos de ce problème.

- -

En conséquence de cette manipulation de l'URL , vous devrez - pensez à confectionner différemment vos règles de réécriture dans un - contexte de niveau répertoire. En particulier, rappelez-vous que le - chemin de répertoire sera absent de l'URL que vos règles de - réécriture verront. Voici quelques exemples qui permettront de - clarifier les choses :

- - - - - - - - - - - - - - - - - - - - - - - -
Position de la règleRègle
Section VirtualHostRewriteRule "^/images/(.+)\.jpg" "/images/$1.gif"
Fichier .htaccess à la racine des documentsRewriteRule "^images/(.+)\.jpg" "images/$1.gif"
Fichier .htaccess dans le répertoire imagesRewriteRule "^(.+)\.jpg" "$1.gif"
- -

Pour une étude plus approfondie de la manière dont - mod_rewrite manipule les URLs dans les différents - contextes, vous pouvez consulter les entrées du journal - générées au cours du processus de - réécriture.

+

Dans un contexte de répertoire, + les règles sont appliquées durant la phase "Fixup" après que l’URL a été + traduit en nom de fichier. Cela modifie ce à quoi correspond le motif et la + manière dont les substitutions sont gérées. Voir le document Réécritures en fonction du + répertoire pour des détails pratiques à propos de la suppression du + chemin, de RewriteBase et de la manière d’éviter un bouclage.

+
Module Processing Order + +

mod_rewrite et mod_alias agissent tous + les deux au cours de la phase de traduction de l’URL en nom de fichier, mais + mod_rewrite opère en premier, quel que soit l’ordre + d’apparition des directives dans le fichier de configuration. Ce + comportement est déterminé par la priorité des points d’accroche + qu’enregistre chaque module, pas par l’ordre du code source.

+ +

La conséquence pratique : lorsque des directives RewriteRule et Redirect (ou RedirectMatch) sont présentent simultanément + dans le même contexte de serveur virtuel ou global au serveur, les règles de + réécriture sont évaluées en premier. Si une règle RewriteRule + correspond et réécrit le chemin d’URL (ou renvoie une redirection), + Redirect ne verra jamais la requête.

+ +

+ Comparaison côte-à-côte des ordres d’opération des modules : dans + un contexte global au serveur, mod_rewrite opère en premier lors de la + phase de traduction du chemin d’URL en nom de fichier, mod_alias + opèrant en second ; dans un contexte de répertoire, mod_alias opère en + premier lors de la phase de traduction du chemin d’URL en nom de + fichier, mod_rewrite opérant plus tard lors de la phase de + correction
+ Figure : Inversion de l’ordre d’opération des modules entre les + contextes global au serveur et de répertoire +

+ + +# Dans cette configuration, le Redirect n’est jamais atteint pour /old, +# car la règle RewriteRule s’applique en premier — même si +# Redirect apparaît plus tôt dans le fichier. +Redirect "/old" "http://example.com/new" +RewriteRule "^/old" "/other" [L] + + + Le contexte de répertoire inverse l’ordre +

Dans un contexte de répertoire, + la situation est différente. Les directives de mod_alias + comme Redirect s’appliquent encore dans la phase de traduction + de l’URL en nom de fichier, mais les directives de + mod_rewrite s’appliquent plus tard, lors de la phase de + correction. Cela signifie que dans un contexte de répertoire, + Redirect est évaluée avant l’application des + règles RewriteRule.

+ + +

Du fait de l’incohérence entre les contextes, mélanger des directives de + mod_rewrite et de mod_alias dans la même + portée est une source courante de confusion. Un conseil simple : choisissez + un module pour une tâche donnée. Si vous avez besoin de conditions de + réécritures ou de comparaison de motif, utilisez exclusivement + RewriteRule. Si une simple redirection de préfixe suffit, + utilisez la directive Redirect et n’ajoutez pas de règles de + réécritures qui pourraient interagir avec elle.

+ +
+ +
Encodage et décodage des URLs + +

Apache httpd supprime l’échappement des caractères encodés pour l’URL + dans le chemin d’URL de la requête avant que toute comparaison de motif de + directive RewriteRule ne soit + effectuée. Une requête pour /my%20page/cats%3Fdogs est décodée + en /my page/cats?dogs, et c’est à cette chaîne décodée qu’est + comparé le motif de la directive RewriteRule.

+ +

Cela signifie que vous ne pouvez pas écrire un motif correspondant à la + forme littérale de l’URL encodé. Si vous devez distinguer + /horses%2Fponies de /horses/ponies, utilisez la + variable %{THE_REQUEST} dans une directive RewriteCond — cette variable conserve la + requête originelle telle qu’elle a été envoyée par le client, avant tout + décodage :

+ + +# Ne correspond qu’au caractère encodé littéral %2F, +# pas au séparateur de chemin réel +RewriteCond "%{THE_REQUEST}" "/horses%2F" +RewriteRule "^/horses/ponies$" "/special-handler" [L] + + +

Après la substitution, mod_rewrite réencode le chemin + d’URL résultant en sortie. Plusieurs drapeaux permettent de contrôler ce + comportement :

+ +
    +
  • [B] : rétablit l’échappement des + références arrières de façon que les caractères spéciaux capturés dans le + chemin d’URL décodé ne soient pas interprétés comme des délimiteurs dans + la substitution.
    • + +
  • [BNP] : si [B] est actif, ce drapeau + encode les espaces en %20 au lieu de + (convient + pour les éléments du chemin, pas pour la chaîne de paramètres).
    • + +
  • [NE] : ce drapeau supprime + l’échappement par défaut des caractères spéciaux dans le résultat de la + substitution, permettant la transmission sans modification des littéraux + #, ? et d’autres caractères lors des + redirections externes.
    • +
+ +
+ Directive AllowEncodedSlashes + +

Par défaut, httpd renvoie un code 404 pour tout URL contenant une barre + oblique encodée (%2F). La directive AllowEncodedSlashes permet de modifier ce + comportement :

+ +
    +
  • Off (valeur par défaut) : rejette %2F avec + un code 404.
    • +
  • On : autorise %2F et le décode en + / avant de le transmettre aux gestionnaires.
    • +
  • NoDecode : autorise %2F, mais le conserve + sous sa forme encodée de façon que l’application dorsale le distingue d’un + séparateur de chemin réel.
    • +
+ +

Lorsqu’on utilise le drapeau [B] avec des + URLs qui peuvent contenir des barres obliques encodées, il est en général + nécessaire d’utiliser AllowEncodedSlashes NoDecode pour éviter + que httpd ne rejette le résultat réencodé.

+ +
+ +
+ +
Traitement du jeu de règles -

Maintenant, quand mod_rewrite se lance dans ces deux phases de - l'API, il lit le jeu de règles configurées depuis la structure - contenant sa configuration (qui a été elle-même créée soit au - démarrage d'Apache pour le contexte du serveur, soit lors du - parcours des répertoires par le noyau d'Apache pour le contexte de - répertoire). Puis le moteur de réécriture est démarré avec le jeu - de règles contenu (une ou plusieurs règles associées à leurs - conditions). En lui-même, le mode opératoire du moteur de - réécriture d'URLs est exactement le même dans les deux contextes - de configuration. Seul le traitement du résultat final diffère.

- -

L'ordre dans lequel les règles sont définies est important car - le moteur de réécriture les traite selon une chronologie - particulière (et pas très évidente). Le principe est le suivant : - le moteur de réécriture traite les règles (les directives RewriteRule) les unes - à la suite des autres, et lorsqu'une règle s'applique, il parcourt - les éventuelles conditions (directives - RewriteConddirectives) associées. - Pour des raisons historiques, les - conditions précèdent les règles, si bien que le déroulement du - contrôle est un peu compliqué. Voir la figure 1 pour plus de - détails.

+

Maintenant, quand mod_rewrite se lance dans ces deux + phases de l'API, il lit le jeu de règles configuré depuis la structure + contenant sa configuration (qui a été elle-même créée soit au démarrage + d'Apache httpd pour le contexte du serveur, soit lors du parcours des + répertoires par le noyau d'Apache httpd pour le contexte de répertoire). + Puis le moteur de réécriture est démarré avec le jeu de règles contenu + (une ou plusieurs règles associées à leurs conditions). En lui-même, le + mode opératoire du moteur de réécriture d'URLs est exactement le même dans + les deux contextes de configuration. Seul le traitement du résultat final + diffère.

+ +

+ Survol du processus de réécriture par requête lors des phases par + serveur et par répertoire
+ Figure 1 :Le processus de réécriture par requête montrant les + deux phases du traitement des règles (par serveur et par répertoire) +

+ +

L'ordre dans lequel les règles sont définies est important car le + moteur de réécriture les traite selon une chronologie particulière (et pas + très évidente). Le principe est le suivant : le moteur de réécriture + traite les règles (les directives RewriteRule) les unes à la suite des + autres, et lorsqu'une règle s'applique, il parcourt les éventuelles + conditions (directives RewriteConddirectives) associées. + Pour des raisons historiques, les conditions précèdent les règles, si bien + que le déroulement du contrôle est un peu compliqué. Voir la figure 2 pour + plus de détails.

Flux des comparaisons des directives RewriteRule et RewriteCond
- Figure 1:Déroulement du contrôle à travers le jeu de - règles de réécriture + alt="Organigramme montrant le flux de contrôle par règle : pour chaque + règle, comparaison du motif avec l’URL, évaluation des conditions + RewriteCond, application de la substitution si les deux opérations + précédentes ont réussi, puis consultation des drapeaux pour déterminer + si l’on doit arrêter le traitement ou continuer avec la règle + suivante" />
+ Figure 2 :Le flux de contrôle en parcourant le jeu de règles de + réécriture

-

L'URL est tout d'abord comparée au +

L'URL est tout d'abord comparé au Modèle de chaque règle. Lorsqu'une règle ne s'applique pas, mod_rewrite stoppe immédiatement le traitement de cette règle et passe à la règle suivante. Si l'URL correspond au @@ -203,8 +292,17 @@ correspondance satisfaites, le traitement de la règle en cours se poursuit avec le remplacement de l'URL par la chaîne de Substitution.

-
+

+ Flux des références arrières entre les directives RewriteRule et + RewriteCond
+ Figure 3 :Le flux des références arrières dans une règle + Tout d’abord, le motif de la règle RewriteRule est comparé ; ses captures + ($1...$9) sont disponibles dans toutes les chaînes de test des conditions + RewriteCond. Les dernières captures du motif de la condition qui + correspondent (%1...%9) sont disponibles dans la substitution. +

+
-