<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1932769:1934245 (outdated) -->
+<!-- English Revision: 1934245 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<li><module>mod_proxy_balancer</module> 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
<module>mod_proxy_balancer</module> pour plus de détails).</li>
<li>un ou plusieurs modules de types de mandataire, ou protocoles
</Proxy>
</highlight>
+ <note><title>Requêtes HTTPS/CONNECT</title>
+ <p>L’instruction générique <code><Proxy "*"></code> 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 <code><Proxy
+ "https://example.com/path/"></code>) ne fonctionnera pas, car les
+ requêtes CONNECT ne comportent pas de chemin.</p></note>
+
<p>Pour plus de détails sur les directives de contrôle d'accès,
voir la documentation du module
<module>mod_authz_host</module>.</p>
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
</Location>
- </highlight>
+ </highlight>
+
+ <p>Notez que <code>force-proxy-request-1.0</code> implique aussi
+ <code>proxy-sendcl</code>, car HTTP/1.0 ne prend pas en charge l’encodage
+ de transfert fractionné. La redirection des corps de requête fractionnés
+ (via <code>proxy-sendchunked</code>) est désactivée si cette option est
+ définie.</p>
<p>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
<p>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
<code>Content-Length</code>. Lorsqu'il fait suivre ce genre de
requête vers le serveur demandé, <module>mod_proxy_http</module>
<compatibility>BalancerGrowth est disponible depuis la version 2.3.13 du
serveur HTTP Apache</compatibility>
<usage>
- <p>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é.</p>
+ <p>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é.</p>
+ <p>La valeur doit être entre 0 et 1000.</p>
</usage>
</directivesynopsis>
<code>localhost</code>) peut être sujet à discussion, mais il est
transmis dans l'en-tête Host: de la requête.</p>
- <note><strong>Note :</strong>Le chemin associé à l'URL
+ <note>Le chemin associé à l'URL
<code>unix:</code> tient compte de la directive
<directive>DefaultRuntimeDir</directive>.</note>
- <note><strong>Note :</strong>Afin d'éviter l'échappement du
+ <note>Afin d'éviter l'échappement du
caractère <code>'|'</code>, la directive
<directive>RewriteRule</directive> doit posséder l'option
<code>[P,NE]</code>.</note>
- <p>Lorsque la directive ProxyPass est utilisée à l'intérieur d'une
- section <directive type="section" module="core"
+ <p>Lorsque la directive ProxyPass est utilisée à l'intérieur d'une section
+ <directive type="section" module="core"
>Location</directive>, le premier argument est omis et le répertoire
local est obtenu à partir de la section <directive type="section"
- module="core">Location</directive>. Il en sera de même dans une
- section <directive type="section"
- module="core">LocationMatch</directive> ; cependant, ProxyPass
- n'interprète pas les expressions rationnelles, et il sera ici
- nécessaire d'utiliser la directive
- <directive>ProxyPassMatch</directive> à la place.</p>
+ module="core">Location</directive>. Lorsque cette directive est utilisée en
+ dehors d’une section <directive type="section"
+ module="core">Location</directive> ou <directive type="section"
+ module="core">LocationMatch</directive>, l’argument <var>chemin</var> est
+ requis. Il en sera de même dans une section <directive type="section"
+ module="core">LocationMatch</directive> ; cependant, ProxyPass n'interprète
+ pas les expressions rationnelles, et il sera ici nécessaire d'utiliser la
+ directive <directive>ProxyPassMatch</directive> à la place.</p>
<p>Supposons que le serveur local a pour adresse
<code>http://example.com/</code> ; alors la ligne</p>
</note>
<note type="warning"><title>Chronologie de prise en compte des directives
ProxyPass au sein des sections Locations</title>
- <p>On ne peut placer
- qu'une seule directive <directive
- module="mod_proxy">ProxyPass</directive> dans une section
- <directive module="core">Location</directive>, et c'est la section
- la plus spécifique qui l'emportera.</p>
+ <p>On ne peut placer qu'une seule directive <directive
+ module="mod_proxy">ProxyPass</directive> dans une section <directive
+ module="core">Location</directive>, et c'est la dernière section
+ <directive module="core">Location</directive> correspondante qui
+ l'emportera, suivant en cela les règles standards de <a
+ href="../sections.html#merging">fusion des sections</a>. Placez les
+ sections <directive module="core">Location</directive> les plus
+ spécifiques <em>après</em> les moins spécifiques afin de s’assurer que la
+ directive <directive module="mod_proxy">ProxyPass</directive> attendue
+ s’applique.</p>
</note>
<note type="warning"><title>Exclusions et variable d'environnement no-proxy</title>
<p>Les exclusions doivent se situer <em>avant</em>
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é.</p> </note>
+
+ <note><title>Mise en commun des connexions avec le MPM prefork</title>
+ <p>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 <code>acquire</code> et <code>ttl</code> qui contrôlent le
+ comportement des pools de connexions n’ont aucun effet si on utilise
+ prefork. Les paramètres de dimensionnement <code>min</code>,
+ <code>smax</code> et <code>hmax</code> sont eux aussi ignorés.</p>
+ </note>
<p>Le paramètre <code>ttl</code>, quant à lui, permet de définir une durée
de vie optionnelle ; les connexions qui n'ont pas été utilisées pendant au
</td></tr>
<tr><td><a id="upgrade" name="upgrade">upgrade</a></td>
<td>-</td>
-
<td><p>Protocole pris en charge par <module>mod_proxy_http</module> ou
+ <td><p>Protocole pris en charge par <module>mod_proxy_http</module> ou
<module>mod_proxy_wstunnel</module> pour le mécanisme de promotion de
protocole HTTP lors d'une négociation du client/navigateur HTTP (en
- accord avec <a
- href="https://www.ietf.org/rfc/rfc9110.html#name-upgrade">RFC 9110 -
- Upgrade</a>). Voir la note <a href="#protoupgrade">Promotion de
- protocole</a> ci-dessous</p>
+ accord avec <rfc anchor="name-upgrade">9110</rfc> - Upgrade). Voir la
+ note <a href="#protoupgrade">Promotion de protocole</a> ci-dessous</p>
</td></tr>
<tr><td>mapping</td>
<td>-</td>
<p><strong>Mot-clés supplémentaires de ProxyPass</strong></p>
- <p>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 <var>PATH_INFO</var>. Le mot-clé optionnel
- <var>nocanon</var> 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.</p>
+ <p>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
+ <var><glossary ref="pathinfo">PATH_INFO</glossary></var>. Le mot-clé
+ optionnel <var>nocanon</var> 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.</p>
<p>Par défaut, mod_proxy inclut la chaîne de paramètres lors de la
génération de la variable d'environnement
toute correspondance entre parenthèses dans la chaîne donnée et
l'utiliser comme nouvelle <var>url</var>.</p>
- <note><strong>Note : </strong>Cette directive ne peut pas être
+ <note>Cette directive ne peut pas être
utilisée dans un contexte de niveau répertoire.</note>
+ <note type="warning"><title>Correspondance de worker avec les références
+ arrières</title>
+ <p>Quand <directive>ProxyPassMatch</directive> contient des références
+ arrières (par exemple <code>$1</code>) dans l’URL cible, chaque requête
+ produit un URL résolu différent. Comme la recherche de correspondance des <a
+ href="#workers">workers</a> 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 :</p>
+ <highlight language="config">
+ProxyPass "/notused" "http://backend.example.com/" connectiontimeout=5 timeout=30
+ProxyPassMatch "^/(.*\.gif)$" "http://backend.example.com/$1"
+ </highlight>
+ <p>La définition explicite du worker <directive>ProxyPass</directive> permet
+ de s’assurer que le jeu de connexions d’arrière-plan est disponible pour les
+ requêtes <directive>ProxyPassMatch</directive>.</p>
+ </note>
+
+
<p>Supposons que le serveur local a pour adresse
<code>http://example.com/</code> ; alors</p>
sous-répertoire donné.</p>
<p>Dans une section <directive type="section"
- module="core">LocationMatch</directive>, le premier argument est
- omis et l'expression rationnelle est obtenue à partir de la directive
- <directive type="section" module="core">LocationMatch</directive>.</p>
+ module="core">LocationMatch</directive>, le premier argument est omis et
+ l'expression rationnelle est obtenue à partir de la directive <directive
+ type="section" module="core">LocationMatch</directive>. En dehors d’une
+ section <directive type="section" module="core">Location</directive> ou
+ <directive type="section" module="core">LocationMatch</directive>,
+ l’argument <var>regex</var> est requis.</p>
<p>Si vous avez besoin d'une configuration du mandataire inverse
plus flexible, voyez la directive <directive
dans la partie protocole d'une URL. </p>
<p>Lorsque cette directive est utilisée dans une section <directive
- type="section" module="core">Location</directive>, le premier
- argument est omis et le répertoire local est obtenu à partir de
- l'argument de la directive <directive type="section"
- module="core">Location</directive>. Il en est de même à l'intérieur
- d'une section <directive type="section"
- module="core">LocationMatch</directive>, 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 <directive type="section"
+ type="section" module="core">Location</directive>, le premier argument est
+ omis et le répertoire local est obtenu à partir de l'argument de la
+ directive <directive type="section" module="core">Location</directive>. En
+ dehors d’une section <directive type="section"
+ module="core">Location</directive> ou <directive type="section"
+ module="core">LocationMatch</directive>, l’argument <var>chemin</var> est
+ requis. Il en est de même à l'intérieur d'une section <directive
+ type="section" module="core">LocationMatch</directive>, 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 <directive type="section"
module="core">Location</directive> séparée.</p>
<p>Cette directive ne peut pas être placée dans une section
<p>Cette directive permet de contrôler l'utilisation de l'en-tête
HTTP <code>Via:</code> 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 <a
- href="https://www.rfc-editor.org/rfc/rfc2616">RFC 2616</a> (HTTP/1.1),
+ de serveurs mandataires. Voir la <rfc>2616</rfc> (HTTP/1.1),
section 14.45 pour une description des lignes d'en-tête
<code>Via:</code>.</p>
projects / thirdparty / apache / httpd.git / commitdiff
