From: Lucien Gentis Date: Sun, 17 May 2026 14:43:11 +0000 (+0000) Subject: fr doc XML file update. X-Git-Url: http://git.ipfire.org/gitweb/index.cgi?a=commitdiff_plain;h=23b16a2de79da6339d044b5db5799d8364557cda;p=thirdparty%2Fapache%2Fhttpd.git fr doc XML file update. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1934301 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_proxy.xml.fr b/docs/manual/mod/mod_proxy.xml.fr index d4f53bfe87..3dab7240aa 100644 --- a/docs/manual/mod/mod_proxy.xml.fr +++ b/docs/manual/mod/mod_proxy.xml.fr @@ -1,7 +1,7 @@ - + @@ -58,7 +58,7 @@
  • mod_proxy_balancer et un ou plusieurs modules de répartition, si la répartition de charge doit être mise en - oeuvre (Voir la documentation de + oeuvre(Voir la documentation de mod_proxy_balancer pour plus de détails).
  • un ou plusieurs modules de types de mandataire, ou protocoles @@ -390,6 +390,15 @@ ProxyPass "/apps" "http://127" </Proxy> + Requêtes HTTPS/CONNECT +

    L’instruction générique <Proxy "*"> ci-dessus + correspond à toutes les requêtes, y compris les requêtes HTTPS sous tunnel + via la méthode CONNECT. Notez que le contrôle d’accès pour les tunnels + CONNECT ne peut fonctionner qu’avec l’hôte et le port — le contrôle avec + le chemin (par exemple <Proxy + "https://example.com/path/">) ne fonctionnera pas, car les + requêtes CONNECT ne comportent pas de chemin.

     +

    Pour plus de détails sur les directives de contrôle d'accès, voir la documentation du module mod_authz_host.

    @@ -469,7 +478,13 @@ ProxyPass "/apps" "http://127" SetEnv force-proxy-request-1.0 1 SetEnv proxy-nokeepalive 1 </Location> - + + +

    Notez que force-proxy-request-1.0 implique aussi + proxy-sendcl, car HTTP/1.0 ne prend pas en charge l’encodage + de transfert fractionné. La redirection des corps de requête fractionnés + (via proxy-sendchunked) est désactivée si cette option est + définie.

    A partir de la version 2.4.26 du serveur HTTP Apache, la définition de la variable d'environnement "no-proxy" permet de désactiver @@ -484,7 +499,7 @@ ProxyPass "/apps" "http://127"

    Certaines méthodes de requêtes comme POST comportent un corps de requête. Le protocole HTTP stipule que les requêtes qui comportent - un corps doivent soit utiliser un codage de transmission + un corps doivent soit utiliser un encodage de transmission fractionnée (chunked transfer encoding), soit envoyer un en-tête de requête Content-Length. Lorsqu'il fait suivre ce genre de requête vers le serveur demandé, mod_proxy_http @@ -841,11 +856,10 @@ après la configuration initiale BalancerGrowth est disponible depuis la version 2.3.13 du serveur HTTP Apache -

    Cette directive permet de définir le nombre de - répartiteurs de charge pouvant - être ajoutés à ceux déjà configurés pour un - serveur virtuel. Elle n'est active que si au minimum un répartiteur - a été préconfiguré.

    +

    Cette directive permet de définir le nombre de répartiteurs de charge + pouvant être ajoutés à ceux déjà configurés pour un serveur virtuel. Elle + n'est active que si au minimum un répartiteur a été préconfiguré.

    +

    La valeur doit être entre 0 et 1000.

    @@ -1047,25 +1061,27 @@ de la version 2.4.7 du serveur HTTP Apache localhost) peut être sujet à discussion, mais il est transmis dans l'en-tête Host: de la requête.

    - Note :Le chemin associé à l'URL + Le chemin associé à l'URL unix: tient compte de la directive DefaultRuntimeDir. - Note :Afin d'éviter l'échappement du + Afin d'éviter l'échappement du caractère '|', la directive RewriteRule doit posséder l'option [P,NE]. -

    Lorsque la directive ProxyPass est utilisée à l'intérieur d'une - section Lorsque la directive ProxyPass est utilisée à l'intérieur d'une section + Location, le premier argument est omis et le répertoire local est obtenu à partir de la section Location. Il en sera de même dans une - section LocationMatch ; cependant, ProxyPass - n'interprète pas les expressions rationnelles, et il sera ici - nécessaire d'utiliser la directive - ProxyPassMatch à la place.

    + module="core">Location. Lorsque cette directive est utilisée en + dehors d’une section Location ou LocationMatch, l’argument chemin est + requis. Il en sera de même dans une section LocationMatch ; cependant, ProxyPass n'interprète + pas les expressions rationnelles, et il sera ici nécessaire d'utiliser la + directive ProxyPassMatch à la place.

    Supposons que le serveur local a pour adresse http://example.com/ ; alors la ligne

    @@ -1157,11 +1173,16 @@ ProxyPass "/mirror/foo/i" "!"     Chronologie de prise en compte des directives ProxyPass au sein des sections Locations -

    On ne peut placer - qu'une seule directive ProxyPass dans une section - Location, et c'est la section - la plus spécifique qui l'emportera.

    +

    On ne peut placer qu'une seule directive ProxyPass dans une section Location, et c'est la dernière section + Location correspondante qui + l'emportera, suivant en cela les règles standards de fusion des sections. Placez les + sections Location les plus + spécifiques après les moins spécifiques afin de s’assurer que la + directive ProxyPass attendue + s’applique.

     Exclusions et variable d'environnement no-proxy

    Les exclusions doivent se situer avant @@ -1198,6 +1219,15 @@ ProxyPass "/mirror/foo/i" "!" autres réglages n'étant pas coordonnés entre ces différents processus, sauf bien entendu lorsqu'un seul processus enfant n'est autorisé par la configuration ou le MPM utilisé.

     + + Mise en commun des connexions avec le MPM prefork +

    Avec le MPM prefork, les connexions avec les serveurs dorsaux ne sont pas + mises en commun (chaque processus enfant gère une connexion à la fois). Les + paramètres acquire et ttl qui contrôlent le + comportement des pools de connexions n’ont aucun effet si on utilise + prefork. Les paramètres de dimensionnement min, + smax et hmax sont eux aussi ignorés.

    +

    Le paramètre ttl, quant à lui, permet de définir une durée de vie optionnelle ; les connexions qui n'ont pas été utilisées pendant au @@ -1463,13 +1493,11 @@ ProxyPass "/mirror/foo/i" "!" upgrade - -

    Protocole pris en charge par mod_proxy_http ou +

    Protocole pris en charge par mod_proxy_http ou mod_proxy_wstunnel pour le mécanisme de promotion de protocole HTTP lors d'une négociation du client/navigateur HTTP (en - accord avec RFC 9110 - - Upgrade). Voir la note Promotion de - protocole ci-dessous

    + accord avec 9110 - Upgrade). Voir la + note Promotion de protocole ci-dessous

    mapping - @@ -1702,15 +1730,15 @@ ProxyPass "/" "balancer://hotcluster/ "

    Mot-clés supplémentaires de ProxyPass

    -

    Normalement, mod_proxy va mettre sous leur forme canonique les - URLs traitées par ProxyPass. Mais ceci peut être incompatible avec - certains serveurs d'arrière-plan, et en particulier avec ceux qui - utilisent PATH_INFO. Le mot-clé optionnel - nocanon modifie ce comportement et permet de transmettre - le chemin d'URL sous sa forme brute au serveur d'arrière-plan. Notez - que ce mot-clé peut affecter la sécurité de votre serveur d'arrière-plan, - car la protection limitée contre les attaques à base d'URL que - fournit le mandataire est alors supprimée.

    +

    Normalement, mod_proxy va mettre sous leur forme canonique les URLs + traitées par ProxyPass. Mais ceci peut être incompatible avec certains + serveurs d'arrière-plan, et en particulier avec ceux qui utilisent + PATH_INFO. Le mot-clé + optionnel nocanon modifie ce comportement et permet de + transmettre le chemin d'URL sous sa forme brute au serveur d'arrière-plan. + Notez que ce mot-clé peut affecter la sécurité de votre serveur + d'arrière-plan, car la protection limitée contre les attaques à base d'URL + que fournit le mandataire est alors supprimée.

    Par défaut, mod_proxy inclut la chaîne de paramètres lors de la génération de la variable d'environnement @@ -1799,9 +1827,30 @@ arrières (voir note ci-dessous). toute correspondance entre parenthèses dans la chaîne donnée et l'utiliser comme nouvelle url.

    - Note : Cette directive ne peut pas être + Cette directive ne peut pas être utilisée dans un contexte de niveau répertoire. + Correspondance de worker avec les références + arrières +

    Quand ProxyPassMatch contient des références + arrières (par exemple $1) dans l’URL cible, chaque requête + produit un URL résolu différent. Comme la recherche de correspondance des workers s’effectue par URL, ces requêtes ne + correspondront pas au worker créé par cette directive et utiliseront à la + place le worker du mandataire inverse par défaut, qui ne réutilise pas les + connexions, ni ne met en cache les recherches DNS. Pour activer la mise en + commun des connexions, définissez un worker explicite pour le serveur dorsal + séparément :

    + +ProxyPass "/notused" "http://backend.example.com/" connectiontimeout=5 timeout=30 +ProxyPassMatch "^/(.*\.gif)$" "http://backend.example.com/$1" + +

    La définition explicite du worker ProxyPass permet + de s’assurer que le jeu de connexions d’arrière-plan est disponible pour les + requêtes ProxyPassMatch.

    +     + +

    Supposons que le serveur local a pour adresse http://example.com/ ; alors

    @@ -1817,9 +1866,12 @@ arrières (voir note ci-dessous). sous-répertoire donné.

    Dans une section LocationMatch, le premier argument est - omis et l'expression rationnelle est obtenue à partir de la directive - LocationMatch.

    + module="core">LocationMatch, le premier argument est omis et + l'expression rationnelle est obtenue à partir de la directive LocationMatch. En dehors d’une + section Location ou + LocationMatch, + l’argument regex est requis.

    Si vous avez besoin d'une configuration du mandataire inverse plus flexible, voyez la directive

    Lorsque cette directive est utilisée dans une section Location, le premier - argument est omis et le répertoire local est obtenu à partir de - l'argument de la directive Location. Il en est de même à l'intérieur - d'une section LocationMatch, mais le résultat ne sera - probablement pas celui attendu car ProxyPassReverse va interpréter - l'expression rationnelle littéralement comme un chemin ; si besoin - est dans ce cas, définissez la directive ProxyPassReverse en dehors - de la section, ou dans une section Location, le premier argument est + omis et le répertoire local est obtenu à partir de l'argument de la + directive Location. En + dehors d’une section Location ou LocationMatch, l’argument chemin est + requis. Il en est de même à l'intérieur d'une section LocationMatch, mais le résultat ne + sera probablement pas celui attendu car ProxyPassReverse va interpréter + l'expression rationnelle littéralement comme un chemin ; si besoin est dans + ce cas, définissez la directive ProxyPassReverse en dehors de la section, ou + dans une section Location séparée.

    Cette directive ne peut pas être placée dans une section @@ -2390,8 +2444,7 @@ ProxyDomain ".example.com"

    Cette directive permet de contrôler l'utilisation de l'en-tête HTTP Via: par le mandataire. Le but recherché est de contrôler le flux des requêtes mandatées tout au long d'une chaîne - de serveurs mandataires. Voir RFC 2616 (HTTP/1.1), + de serveurs mandataires. Voir la 2616 (HTTP/1.1), section 14.45 pour une description des lignes d'en-tête Via:.