<?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: 1932768:1933855 (outdated) -->
+<!-- English Revision: 1933855 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
</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
être ajoutés au groupe de répartition de charge préconfiguré d'un
serveur virtuel. Elle n'est active que si le groupe a été
préconfiguré avec un membre au minimum.</p>
+ <p>La valeur doit être entre 0 et 1000.</p>
</usage>
</directivesynopsis>
et cibler l'UDS /home/www.socket, vous devez utiliser
<code>unix:/home/www.socket|http://localhost/whatever/</code>.</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>
<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
+ 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>.
+ 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 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>
règles situées après une règle dont l'URL correspond au début de
leur propre URL seront ignorées. Notez que tout ceci est en
relation avec le partage de workers.</p>
-
</note>
- <note type="warning"><title>Chronologie de prise en compte des directives
+
+ <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>
les directives <directive>ProxyPass</directive> générales. A partir de la
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
</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 la <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>
des versions 2.4.48 et ultérieures désactive la prise en charge par
<module>mod_proxy_http</module>), voir la documentation de
<module>mod_proxy_wstunnel</module> pour la méthode permettant de mandater
- le protocole WebSocket.</p>
- </note>
+ le protocole WebSocket.</p></note>
</usage>
</directivesynopsis>
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
supportée 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="http://www.ietf.org/rfc/rfc2616.txt">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
