You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by lg...@apache.org on 2016/05/07 16:30:39 UTC
svn commit: r1742729 [4/5] - in /httpd/httpd/branches/2.4.x/docs/manual: ./
mod/ rewrite/
Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/mod_proxy.xml.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/mod_proxy.xml.fr?rev=1742729&r1=1742728&r2=1742729&view=diff
==============================================================================
--- httpd/httpd/branches/2.4.x/docs/manual/mod/mod_proxy.xml.fr (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/mod/mod_proxy.xml.fr Sat May 7 16:30:39 2016
@@ -1,7 +1,7 @@
-<?xml version="1.0"?>
+<?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: 1718324 -->
+<!-- English Revision: 1741864 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
@@ -32,34 +32,34 @@
<summary>
<note type="warning"><title>Avertissement</title>
- <p>N'activez pas la fonctionnalité de mandataire avec la directive
+ <p>N'activez pas la fonctionnalité de mandataire avec la directive
<directive module="mod_proxy">ProxyRequests</directive> avant
- d'avoir <a href="#access">sécurisé votre serveur</a>. Les serveurs
- mandataires ouverts sont dangereux pour votre réseau,
+ d'avoir <a href="#access">sécurisé votre serveur</a>. Les serveurs
+ mandataires ouverts sont dangereux pour votre réseau,
mais aussi pour l'Internet au sens large.</p>
</note>
- <p><module>mod_proxy</module> et ses modules associés implémentent
+ <p><module>mod_proxy</module> et ses modules associés implémentent
un mandataire/passerelle pour le serveur HTTP Apache, et supportent
de nombreux protocoles courants, ainsi que plusieurs algorithmes de
- répartition de charge. Le support de protocoles et d'algorithmes de
- répartition de charge supplémentaires peut être assuré par des
+ répartition de charge. Le support de protocoles et d'algorithmes de
+ répartition de charge supplémentaires peut être assuré par des
modules tiers.</p>
- <p>Un jeu de modules chargés dans le serveur permet de fournir les
- fonctionnalités souhaitées. Ces modules peuvent être inclus
- statiquement à la compilation, ou dynamiquement via la directive
+ <p>Un jeu de modules chargés dans le serveur permet de fournir les
+ fonctionnalités souhaitées. Ces modules peuvent être inclus
+ statiquement à la compilation, ou dynamiquement via la directive
<directive module="mod_so">LoadModule</directive>. Ce jeu de module
doit comporter :</p>
<ul>
- <li><module>mod_proxy</module>, qui fournit les fonctionnalités de
+ <li><module>mod_proxy</module>, qui fournit les fonctionnalités de
base d'un mandataire</li>
<li><module>mod_proxy_balancer</module> et un ou plusieurs modules
- de répartition, si la répartition de charge doit être mise en
+ de répartition, si la répartition de charge doit être mise en
oeuvre (Voir la documentation de
- <module>mod_proxy_balancer</module> pour plus de détails).</li>
+ <module>mod_proxy_balancer</module> pour plus de détails).</li>
<li>un ou plusieurs modules de types de mandataire, ou protocoles
:
@@ -80,13 +80,13 @@
</li>
</ul>
- <p>En outre, d'autres modules fournissent des fonctionnalités
- étendues. <module>mod_cache</module> et ses modules associés
+ <p>En outre, d'autres modules fournissent des fonctionnalités
+ étendues. <module>mod_cache</module> et ses modules associés
fournissent la mise en cache. Les directives <code>SSLProxy*</code>
du module <module>mod_ssl</module> permettent de contacter des
serveurs distants en utilisant le protocole SSL/TLS. Ces modules
- additionnels devront être chargés et configurés pour pouvoir
- disposer de ces fonctionnalités.</p>
+ additionnels devront être chargés et configurés pour pouvoir
+ disposer de ces fonctionnalités.</p>
</summary>
<seealso><module>mod_cache</module></seealso>
<seealso><module>mod_proxy_ajp</module></seealso>
@@ -101,69 +101,69 @@
<section id="forwardreverse"><title>Mandataires directs et
mandataires/passerelles inverses</title>
- <p>Le serveur HTTP Apache peut être configuré dans les deux modes mandataire
- <dfn>direct</dfn> et mandataire <dfn>inverse</dfn> (aussi nommé
+ <p>Le serveur HTTP Apache peut être configuré dans les deux modes mandataire
+ <dfn>direct</dfn> et mandataire <dfn>inverse</dfn> (aussi nommé
mode <dfn>passerelle</dfn>).</p>
<p>Un <dfn>mandataire direct</dfn> standard est un serveur
- intermédiaire qui s'intercale entre le client et le <em>serveur
- demandé</em>. Pour obtenir un contenu hébergé par
- le serveur demandé, le client envoie une requête au
- mandataire en nommant le serveur demandé comme
+ intermédiaire qui s'intercale entre le client et le <em>serveur
+ demandé</em>. Pour obtenir un contenu hébergé par
+ le serveur demandé, le client envoie une requête au
+ mandataire en nommant le serveur demandé comme
cible. Le mandataire extrait alors le contenu depuis le
- serveur demandé et le renvoie enfin au client. Le client doit être
- configuré de manière appropriée pour pouvoir utiliser le mandataire
- direct afin d'accéder à d'autres sites.</p>
+ serveur demandé et le renvoie enfin au client. Le client doit être
+ configuré de manière appropriée pour pouvoir utiliser le mandataire
+ direct afin d'accéder à d'autres sites.</p>
- <p>L'accès à Internet depuis des clients situés derrière un
+ <p>L'accès à Internet depuis des clients situés derrière un
pare-feu est une utilisation typique du mandataire direct. Le
mandataire direct peut aussi utiliser la mise en cache (fournie
- par <module>mod_cache</module>) pour réduire la charge du
- réseau.</p>
+ par <module>mod_cache</module>) pour réduire la charge du
+ réseau.</p>
- <p>La fonctionnalité de mandataire direct est activée via la
+ <p>La fonctionnalité de mandataire direct est activée via la
directive <directive module="mod_proxy">ProxyRequests</directive>.
- Comme les mandataires directs permettent aux clients d'accéder à
+ Comme les mandataires directs permettent aux clients d'accéder à
des sites quelconques via votre serveur et de dissimuler leur
- véritable origine, il est indispensable de <a
- href="#access">sécuriser votre serveur</a> de façon à ce que seuls
- les clients autorisés puissent accéder à votre serveur avant
- d'activer la fonctionnalité de mandataire direct.</p>
+ véritable origine, il est indispensable de <a
+ href="#access">sécuriser votre serveur</a> de façon à ce que seuls
+ les clients autorisés puissent accéder à votre serveur avant
+ d'activer la fonctionnalité de mandataire direct.</p>
<p>Un <dfn>mandataire inverse</dfn> (ou <dfn>passerelle</dfn>),
- quant à lui, apparaît au client comme un serveur web standard.
- Aucune configuration particulière du client n'est nécessaire. Le
+ quant à lui, apparaît au client comme un serveur web standard.
+ Aucune configuration particulière du client n'est nécessaire. Le
client adresse ses demandes de contenus ordinaires dans l'espace
- de nommage du mandataire inverse. Ce dernier décide alors où
- envoyer ces requêtes, et renvoie le contenu au client comme s'il
- l'hébergeait lui-même.</p>
+ de nommage du mandataire inverse. Ce dernier décide alors où
+ envoyer ces requêtes, et renvoie le contenu au client comme s'il
+ l'hébergeait lui-même.</p>
- <p>L'accès d'utilisateurs depuis Internet vers un serveur situé
- derrière un pare-feu est une utilisation typique du mandataire
+ <p>L'accès d'utilisateurs depuis Internet vers un serveur situé
+ derrière un pare-feu est une utilisation typique du mandataire
inverse. On peut aussi utiliser les mandataires inverses pour
- mettre en oeuvre une répartition de charge entre plusieurs
- serveurs en arrière-plan, ou fournir un cache pour un serveur
- d'arrière-plan plus lent. Les mandataires inverses peuvent aussi
- tout simplement servir à rassembler plusieurs serveurs dans le
- même espace de nommage d'URLs.</p>
+ mettre en oeuvre une répartition de charge entre plusieurs
+ serveurs en arrière-plan, ou fournir un cache pour un serveur
+ d'arrière-plan plus lent. Les mandataires inverses peuvent aussi
+ tout simplement servir à rassembler plusieurs serveurs dans le
+ même espace de nommage d'URLs.</p>
- <p>La fonctionnalité de mandataire inverse est activée via la
+ <p>La fonctionnalité de mandataire inverse est activée via la
directive <directive module="mod_proxy">ProxyPass</directive> ou
le drapeau <code>[P]</code> de la directive <directive
module="mod_rewrite">RewriteRule</directive>. Il n'est
- <strong>pas</strong> nécessaire de définir <directive
+ <strong>pas</strong> nécessaire de définir <directive
module="mod_proxy">ProxyRequests</directive> pour configurer
un mandataire inverse.</p>
</section> <!-- /forwardreverse -->
<section id="examples"><title>Exemples simples</title>
- <p>Les exemples ci-dessous illustrent de manière très basique la
- mise en oeuvre de la fonctionnalité de mandataire et ne sont là que
- pour vous aider à démarrer. Reportez-vous à la documentation de
+ <p>Les exemples ci-dessous illustrent de manière très basique la
+ mise en oeuvre de la fonctionnalité de mandataire et ne sont là que
+ pour vous aider à démarrer. Reportez-vous à la documentation de
chaque directive.</p>
- <p>Si en outre, vous désirez activer la mise en cache, consultez la
+ <p>Si en outre, vous désirez activer la mise en cache, consultez la
documentation de <module>mod_cache</module>.</p>
<example><title>Mandataire inverse</title>
@@ -185,48 +185,48 @@ ProxyVia On
</example>
</section> <!-- /examples -->
- <section id="handler"><title>Accès via un gestionnaire</title>
+ <section id="handler"><title>Accès via un gestionnaire</title>
- <p>Vous pouvez aussi forcer le traitement d'une requête en tant que
- requête de mandataire inverse en créant un gestionnaire de transfert
- approprié. Dans l'exemple suivant, toutes les requêtes pour
+ <p>Vous pouvez aussi forcer le traitement d'une requête en tant que
+ requête de mandataire inverse en créant un gestionnaire de transfert
+ approprié. Dans l'exemple suivant, toutes les requêtes pour
des scripts PHP seront transmises au serveur FastCGI
- spécifié via un mandat inverse :
+ spécifié via un mandat inverse :
</p>
<example><title>Scripts PHP et mandataire inverse</title>
<highlight language="config">
<FilesMatch "\.php$">
- # Les sockets Unix nécessitent une version 2.4.7 ou supérieure du
+ # Les sockets Unix nécessitent une version 2.4.7 ou supérieure du
# serveur HTTP Apache
SetHandler "proxy:unix:/path/to/app.sock|fcgi://localhost/"
</FilesMatch>
</highlight>
</example>
- <p>Cette fonctionnalité est disponible à partir de la version
+ <p>Cette fonctionnalité est disponible à partir de la version
2.4.10 du serveur HTTP Apache.</p>
</section> <!-- /handler -->
<section id="workers"><title>Workers</title>
- <p>Le mandataire gère la configuration et les paramètres de
- communication des serveurs originaux au sein d'objets nommés
+ <p>Le mandataire gère la configuration et les paramètres de
+ communication des serveurs originaux au sein d'objets nommés
<dfn>workers</dfn>. Deux types de worker sont fournis : le worker
- par défaut du mandataire direct et le worker par défaut du
- mandataire inverse. Il est aussi possible de définir explicitement
- des workers supplémentaires.</p>
-
- <p>Les deux workers par défaut possèdent une configuration figée
- et seront utilisés si aucun autre worker ne correspond à la
- requête. Ils n'utilisent ni les jeux de connexions (connection
+ par défaut du mandataire direct et le worker par défaut du
+ mandataire inverse. Il est aussi possible de définir explicitement
+ des workers supplémentaires.</p>
+
+ <p>Les deux workers par défaut possèdent une configuration figée
+ et seront utilisés si aucun autre worker ne correspond à la
+ requête. Ils n'utilisent ni les jeux de connexions (connection
pooling), ni les
connexions HTTP persistantes (Keep-Alive). En effet, les
- connexions TCP vers le serveur original sont fermées et ouvertes
- pour chaque requête.</p>
+ connexions TCP vers le serveur original sont fermées et ouvertes
+ pour chaque requête.</p>
- <p>Les workers définis explicitement sont identifiés par leur URL.
- Ils sont en général définis via les directives <directive
+ <p>Les workers définis explicitement sont identifiés par leur URL.
+ Ils sont en général définis via les directives <directive
module="mod_proxy">ProxyPass</directive> ou <directive
module="mod_proxy">ProxyPassMatch</directive> lorsqu'on les
utilise dans le cadre d'un mandataire inverse :</p>
@@ -238,10 +238,10 @@ ProxyVia On
</example>
- <p>Cette directive va créer un worker associé à l'URL du serveur
+ <p>Cette directive va créer un worker associé à l'URL du serveur
original <code>http://backend.example.com</code> qui utilisera les
- valeurs de timeout données. Lorsqu'ils sont utilisés dans le cadre
- d'un mandataire direct, les workers sont en général définis via la
+ valeurs de timeout données. Lorsqu'ils sont utilisés dans le cadre
+ d'un mandataire direct, les workers sont en général définis via la
directive <directive module="mod_proxy">ProxySet</directive>,</p>
<example>
@@ -261,36 +261,36 @@ ProxyVia On
</Proxy>
</highlight>
- <p>L'utilisation de workers définis explicitement dans le mode
- mandataire direct n'est pas très courante, car les mandataires
- directs communiquent en général avec de nombreux serveurs
- originaux. La création explicite de workers pour certains serveurs
- originaux peut cependant s'avérer utile si ces serveurs sont
- très souvent sollicités. A leur niveau, les workers explicitement
- définis ne possèdent aucune notion de mandataire direct ou
+ <p>L'utilisation de workers définis explicitement dans le mode
+ mandataire direct n'est pas très courante, car les mandataires
+ directs communiquent en général avec de nombreux serveurs
+ originaux. La création explicite de workers pour certains serveurs
+ originaux peut cependant s'avérer utile si ces serveurs sont
+ très souvent sollicités. A leur niveau, les workers explicitement
+ définis ne possèdent aucune notion de mandataire direct ou
inverse. Ils encapsulent un concept de communication commun avec
- les serveurs originaux. Un worker créé via la directive <directive
- module="mod_proxy">ProxyPass</directive> pour être utilisé dans le
- cadre d'un mandataire inverse sera aussi utilisé dans le cadre
+ les serveurs originaux. Un worker créé via la directive <directive
+ module="mod_proxy">ProxyPass</directive> pour être utilisé dans le
+ cadre d'un mandataire inverse sera aussi utilisé dans le cadre
d'un mandataire directe chaque fois que l'URL vers le serveur
- original correspondra à l'URL du worker, et vice versa.</p>
+ original correspondra à l'URL du worker, et vice versa.</p>
- <p>L'URL qui identifie un worker correspond à l'URL de son serveur
- original, y compris un éventuel chemin donné :</p>
+ <p>L'URL qui identifie un worker correspond à l'URL de son serveur
+ original, y compris un éventuel chemin donné :</p>
<highlight language="config">
ProxyPass "/examples" "http://backend.example.com/examples"
ProxyPass "/docs" "http://backend.example.com/docs"
</highlight>
- <p>Dans cet exemple, deux workers différents sont définis, chacun
+ <p>Dans cet exemple, deux workers différents sont définis, chacun
d'eux utilisant des configurations et jeux de connexions
- séparés.</p>
+ séparés.</p>
<note type="warning"><title>Partage de workers</title>
<p>Le partage de workers intervient lorsque les URLs des workers
s'entrecoupent, ce qui arrive lorsque l'URL d'un worker
- correspond au début de l'URL d'un autre worker défini plus loin
+ correspond au début de l'URL d'un autre worker défini plus loin
dans le fichier de configuration. Dans l'exemple suivant,</p>
<highlight language="config">
@@ -298,58 +298,58 @@ ProxyPass "/apps" "http://backend.exampl
ProxyPass "/examples" "http://backend.example.com/examples" timeout=10
</highlight>
- <p>le second worker n'est pas vraiment créé. C'est le premier
- worker qui est en fait utilisé. L'avantage de ceci réside dans
+ <p>le second worker n'est pas vraiment créé. C'est le premier
+ worker qui est en fait utilisé. L'avantage de ceci réside dans
le fait qu'il n'existe qu'un seul jeu de connexions, ces
- dernières étant donc réutilisées plus souvent. Notez que tous
- les attributs de configuration définis explicitement pour le
- deuxième worker seront ignorés, ce qui sera journalisé en tant
+ dernières étant donc réutilisées plus souvent. Notez que tous
+ les attributs de configuration définis explicitement pour le
+ deuxième worker seront ignorés, ce qui sera journalisé en tant
qu'avertissement. Ainsi, dans l'exemple ci-dessus, la valeur de
timeout retenue pour l'URL <code>/exemples</code> sera
<code>60</code>, et non <code>10</code> !</p>
- <p>Si vous voulez empêcher le partage de workers, classez vos
- définitions de workers selon la longueur des URLs, de la plus
- longue à la plus courte. Si au contraire vous voulez favoriser
+ <p>Si vous voulez empêcher le partage de workers, classez vos
+ définitions de workers selon la longueur des URLs, de la plus
+ longue à la plus courte. Si au contraire vous voulez favoriser
ce partage, utilisez l'ordre de classement inverse. Voir aussi
- l'avertissement à propos de l'ordre de classement des directives
+ l'avertissement à propos de l'ordre de classement des directives
<directive module="mod_proxy">ProxyPass</directive>.</p>
</note> <!-- /worker_sharing -->
- <p>Les workers définis explicitement sont de deux sortes :
- <dfn>workers directs</dfn> et <dfn>workers de répartition (de
+ <p>Les workers définis explicitement sont de deux sortes :
+ <dfn>workers directs</dfn> et <dfn>workers de répartition (de
charge)</dfn>. Ils supportent de nombreux attributs de
- configuration importants décrits dans la directive <directive
- module="mod_proxy">ProxyPass</directive>. Ces mêmes attributs
- peuvent aussi être définis via la directive <directive
+ configuration importants décrits dans la directive <directive
+ module="mod_proxy">ProxyPass</directive>. Ces mêmes attributs
+ peuvent aussi être définis via la directive <directive
module="mod_proxy">ProxySet</directive>.</p>
- <p>Le jeu d'options disponibles pour un worker direct dépend du
- protocole spécifié dans l'URL du serveur original. Les protocoles
+ <p>Le jeu d'options disponibles pour un worker direct dépend du
+ protocole spécifié dans l'URL du serveur original. Les protocoles
disponibles comprennent <code>ajp</code>, <code>fcgi</code>,
<code>ftp</code>, <code>http</code> et <code>scgi</code>.</p>
- <p>Les workers de répartition sont des workers virtuels qui
+ <p>Les workers de répartition sont des workers virtuels qui
utilisent les workers directs, connus comme faisant partie de leurs
- membres, pour le traitement effectif des requêtes. Chaque
- répartiteur peut comporter plusieurs membres. Lorsqu'il traite une
- requête, il choisit un de ses membres en fonction de l'algorithme
- de répartition de charge défini.</p>
+ membres, pour le traitement effectif des requêtes. Chaque
+ répartiteur peut comporter plusieurs membres. Lorsqu'il traite une
+ requête, il choisit un de ses membres en fonction de l'algorithme
+ de répartition de charge défini.</p>
- <p>Un worker de répartition est créé si son URL de worker comporte
+ <p>Un worker de répartition est créé si son URL de worker comporte
<code>balancer</code> comme indicateur de protocole. L'URL du
- répartiteur permet d'identifier de manière unique le worker de
- répartition. La directive <directive
+ répartiteur permet d'identifier de manière unique le worker de
+ répartition. La directive <directive
module="mod_proxy">BalancerMember</directive> permet d'ajouter des
- membres au répartiteur.</p>
+ membres au répartiteur.</p>
</section> <!-- /workers -->
- <section id="access"><title>Contrôler l'accès à votre
+ <section id="access"><title>Contrôler l'accès à votre
mandataire</title>
- <p>Vous pouvez restreindre l'accès à votre mandataire via le bloc
- de contrôle <directive
+ <p>Vous pouvez restreindre l'accès à votre mandataire via le bloc
+ de contrôle <directive
module="mod_proxy" type="section">Proxy</directive> comme dans
l'exemple suivant :</p>
@@ -359,74 +359,74 @@ ProxyPass "/examples" "http://backend.ex
</Proxy>
</highlight>
- <p>Pour plus de détails sur les directives de contrôle d'accès,
+ <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>
- <p>Restreindre l'accès de manière stricte est essentiel si vous
- mettez en oeuvre un mandataire direct (en définissant la directive
- <directive module="mod_proxy">ProxyRequests</directive> à "on").
- Dans le cas contraire, votre serveur pourrait être utilisé par
- n'importe quel client pour accéder à des serveurs quelconques,
- tout en masquant sa véritable identité. Ceci représente un danger
- non seulement pour votre réseau, mais aussi pour l'Internet au
+ <p>Restreindre l'accès de manière stricte est essentiel si vous
+ mettez en oeuvre un mandataire direct (en définissant la directive
+ <directive module="mod_proxy">ProxyRequests</directive> à "on").
+ Dans le cas contraire, votre serveur pourrait être utilisé par
+ n'importe quel client pour accéder à des serveurs quelconques,
+ tout en masquant sa véritable identité. Ceci représente un danger
+ non seulement pour votre réseau, mais aussi pour l'Internet au
sens large. Dans le cas de la mise en oeuvre d'un mandataire
inverse (en utilisant la directive <directive
- module="mod_proxy">ProxyPass</directive> avec <code>ProxyRequests Off</code>), le contrôle
- d'accès est moins critique car les clients ne peuvent contacter
- que les serveurs que vous avez spécifiés.</p>
+ module="mod_proxy">ProxyPass</directive> avec <code>ProxyRequests Off</code>), le contrôle
+ d'accès est moins critique car les clients ne peuvent contacter
+ que les serveurs que vous avez spécifiés.</p>
<p><strong>Voir aussi</strong> la variable d'environnement <a
href="mod_proxy_http.html#env">Proxy-Chain-Auth</a>.</p>
</section> <!-- /access -->
- <section id="startup"><title>Ralentissement au démarrage</title>
+ <section id="startup"><title>Ralentissement au démarrage</title>
<p>Si vous utilisez la directive <directive module="mod_proxy"
- >ProxyBlock</directive>, les noms d'hôtes sont résolus en adresses
- IP puis ces dernières mises en cache au cours du démarrage
- à des fins de tests de comparaisons ultérieurs. Ce processus peut
+ >ProxyBlock</directive>, les noms d'hôtes sont résolus en adresses
+ IP puis ces dernières mises en cache au cours du démarrage
+ à des fins de tests de comparaisons ultérieurs. Ce processus peut
durer plusieurs secondes (ou d'avantage) en fonction de la vitesse
- à laquelle s'effectue la résolution des noms d'hôtes.</p>
+ à laquelle s'effectue la résolution des noms d'hôtes.</p>
</section> <!-- /startup -->
<section id="intranet"><title>Mandataire en Intranet</title>
- <p>Un serveur mandataire Apache httpd situé à l'intérieur d'un Intranet
- doit faire suivre les requêtes destinées à un serveur externe à
- travers le pare-feu de l'entreprise (pour ce faire, définissez la
+ <p>Un serveur mandataire Apache httpd situé à l'intérieur d'un Intranet
+ doit faire suivre les requêtes destinées à un serveur externe à
+ travers le pare-feu de l'entreprise (pour ce faire, définissez la
directive <directive module="mod_proxy">ProxyRemote</directive> de
- façon à ce qu'elle fasse suivre le <var>protocole</var> concerné
- vers le mandataire du pare-feu). Cependant, lorsqu'il doit accéder
- à des ressources situées dans l'Intranet, il peut se passer du
- pare-feu pour accéder aux serveurs. A cet effet, la directive
+ façon à ce qu'elle fasse suivre le <var>protocole</var> concerné
+ vers le mandataire du pare-feu). Cependant, lorsqu'il doit accéder
+ à des ressources situées dans l'Intranet, il peut se passer du
+ pare-feu pour accéder aux serveurs. A cet effet, la directive
<directive module="mod_proxy">NoProxy</directive> permet de
- spécifier quels hôtes appartiennent à l'Intranet et peuvent donc
- être accédés directement.</p>
+ spécifier quels hôtes appartiennent à l'Intranet et peuvent donc
+ être accédés directement.</p>
- <p>Les utilisateurs d'un Intranet ont tendance à oublier le nom du
- domaine local dans leurs requêtes WWW, et demandent par exemple
+ <p>Les utilisateurs d'un Intranet ont tendance à oublier le nom du
+ domaine local dans leurs requêtes WWW, et demandent par exemple
"http://un-serveur/" au lieu de
<code>http://un-serveur.example.com/</code>. Certains serveurs
- mandataires commerciaux acceptent ce genre de requête et les
+ mandataires commerciaux acceptent ce genre de requête et les
traitent simplement en utilisant un nom de domaine local
implicite. Lorsque la directive <directive
- module="mod_proxy">ProxyDomain</directive> est utilisée et si le
- serveur est <a href="#proxyrequests">configuré comme
- mandataire</a>, Apache httpd peut renvoyer une réponse de redirection et
+ module="mod_proxy">ProxyDomain</directive> est utilisée et si le
+ serveur est <a href="#proxyrequests">configuré comme
+ mandataire</a>, Apache httpd peut renvoyer une réponse de redirection et
ainsi fournir au client l'adresse de serveur correcte,
- entièrement qualifiée. C'est la méthode à privilégier car le
+ entièrement qualifiée. C'est la méthode à privilégier car le
fichier des marque-pages de l'utilisateur contiendra alors des
- noms de serveurs entièrement qualifiés.</p>
+ noms de serveurs entièrement qualifiés.</p>
</section> <!-- /intranet -->
<section id="envsettings"><title>Ajustements relatifs au
protocole</title>
- <p>Pour les cas où <module>mod_proxy</module> envoie des requêtes
- vers un serveur qui n'implémente pas correctement les connexions
+ <p>Pour les cas où <module>mod_proxy</module> envoie des requêtes
+ vers un serveur qui n'implémente pas correctement les connexions
persistantes ou le protocole HTTP/1.1, il existe deux variables
- d'environnement qui permettent de forcer les requêtes à utiliser
+ d'environnement qui permettent de forcer les requêtes à utiliser
le protocole HTTP/1.0 avec connexions non persistantes. Elles
- peuvent être définies via la directive <directive
+ peuvent être définies via la directive <directive
module="mod_env">SetEnv</directive>.</p>
<p>Il s'agit des variables <code>force-proxy-request-1.0</code> et
@@ -442,79 +442,79 @@ ProxyPass "/examples" "http://backend.ex
</section> <!-- /envsettings -->
- <section id="request-bodies"><title>Corps de requêtes</title>
+ <section id="request-bodies"><title>Corps de requêtes</title>
- <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
+ <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
- fractionnée (chunked transfer encoding), soit envoyer un en-tête de requête
+ 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>
- s'efforce toujours d'envoyer l'en-tête <code>Content-Length</code>.
- Par contre, si la taille du corps est importante, et si la requête
- originale utilise un codage à fractionnement, ce dernier peut aussi
- être utilisé dans la requête montante. Ce comportement peut être
- contrôlé à l'aide de <a href="../env.html">variables
- d'environnement</a>. Ainsi, si elle est définie, la variable
- <code>proxy-sendcl</code> assure une compatibilité maximale avec les
- serveurs demandés en imposant l'envoi de l'en-tête
+ requête vers le serveur demandé, <module>mod_proxy_http</module>
+ s'efforce toujours d'envoyer l'en-tête <code>Content-Length</code>.
+ Par contre, si la taille du corps est importante, et si la requête
+ originale utilise un codage à fractionnement, ce dernier peut aussi
+ être utilisé dans la requête montante. Ce comportement peut être
+ contrôlé à l'aide de <a href="../env.html">variables
+ d'environnement</a>. Ainsi, si elle est définie, la variable
+ <code>proxy-sendcl</code> assure une compatibilité maximale avec les
+ serveurs demandés en imposant l'envoi de l'en-tête
<code>Content-Length</code>, alors que
<code>proxy-sendchunked</code> diminue la consommation de ressources
- en imposant l'utilisation d'un codage à fractionnement.</p>
+ en imposant l'utilisation d'un codage à fractionnement.</p>
<p>Dans certaines circonstances, le serveur doit mettre en file
- d'attente sur disque les corps de requêtes afin de satisfaire le
- traitement demandé des corps de requêtes. Par exemple, cette mise en
- file d'attente se produira si le corps original a été envoyé selon un
- codage morcelé (et possède une taille importante), alors que
- l'administrateur a demandé que les requêtes du serveur
- d'arrière-plan soient envoyées avec l'en-tête Content-Length ou en
+ d'attente sur disque les corps de requêtes afin de satisfaire le
+ traitement demandé des corps de requêtes. Par exemple, cette mise en
+ file d'attente se produira si le corps original a été envoyé selon un
+ codage morcelé (et possède une taille importante), alors que
+ l'administrateur a demandé que les requêtes du serveur
+ d'arrière-plan soient envoyées avec l'en-tête Content-Length ou en
HTTP/1.0. Cette mise en file d'attente se produira aussi si le corps
- de la requête contient déjà un en-tête Content-Length, alors que le
- serveur est configuré pour filtrer les corps des requêtes entrantes.</p>
+ de la requête contient déjà un en-tête Content-Length, alors que le
+ serveur est configuré pour filtrer les corps des requêtes entrantes.</p>
<p>La directive <directive
module="core">LimitRequestBody</directive> ne s'applique qu'aux
- corps de requêtes que le serveur met en file d'attente sur disque.</p>
+ corps de requêtes que le serveur met en file d'attente sur disque.</p>
</section> <!-- /request-bodies -->
- <section id="x-headers"><title>En-têtes de requête du mandataire
+ <section id="x-headers"><title>En-têtes de requête du mandataire
inverse</title>
- <p>Lorsqu'il est configuré en mode mandataire inverse (en utilisant
+ <p>Lorsqu'il est configuré en mode mandataire inverse (en utilisant
par exemple la directive <directive
module="mod_proxy">ProxyPass</directive>),
- <module>mod_proxy_http</module> ajoute plusieurs en-têtes de requête
- afin de transmettre des informations au serveur demandé. Ces
- en-têtes sont les suivants :</p>
+ <module>mod_proxy_http</module> ajoute plusieurs en-têtes de requête
+ afin de transmettre des informations au serveur demandé. Ces
+ en-têtes sont les suivants :</p>
<dl>
<dt><code>X-Forwarded-For</code></dt>
<dd>L'adresse IP du client.</dd>
<dt><code>X-Forwarded-Host</code></dt>
- <dd>L'hôte d'origine demandé par le client dans l'en-tête de
- requête HTTP <code>Host</code>.</dd>
+ <dd>L'hôte d'origine demandé par le client dans l'en-tête de
+ requête HTTP <code>Host</code>.</dd>
<dt><code>X-Forwarded-Server</code></dt>
- <dd>Le nom d'hôte du serveur mandataire.</dd>
+ <dd>Le nom d'hôte du serveur mandataire.</dd>
</dl>
- <p>Ces en-têtes doivent être utilisés avec précautions sur le
- serveur demandé, car ils contiendront plus d'une valeur (séparées
- par des virgules) si la requête originale contenait déjà un de ces
- en-têtes. Par exemple, vous pouvez utiliser
- <code>%{X-Forwarded-For}i</code> dans la chaîne de format du journal
- du serveur demandé pour enregistrer les adresses IP des clients
+ <p>Ces en-têtes doivent être utilisés avec précautions sur le
+ serveur demandé, car ils contiendront plus d'une valeur (séparées
+ par des virgules) si la requête originale contenait déjà un de ces
+ en-têtes. Par exemple, vous pouvez utiliser
+ <code>%{X-Forwarded-For}i</code> dans la chaîne de format du journal
+ du serveur demandé pour enregistrer les adresses IP des clients
originaux, mais il est possible que vous obteniez plusieurs adresses
- si la requête passe à travers plusieurs mandataires.</p>
+ si la requête passe à travers plusieurs mandataires.</p>
<p>Voir aussi les directives <directive
module="mod_proxy">ProxyPreserveHost</directive> et <directive
module="mod_proxy">ProxyVia</directive> directives, qui permettent
- de contrôler d'autres en-têtes de requête.</p>
+ de contrôler d'autres en-têtes de requête.</p>
- <p>Note : Si vous devez ajouter des en-têtes particuliers à la
- requête mandatée, utilisez la directive <directive
+ <p>Note : Si vous devez ajouter des en-têtes particuliers à la
+ requête mandatée, utilisez la directive <directive
module="mod_headers">RequestHeader</directive>.</p>
</section> <!--/x-headers -->
@@ -522,19 +522,19 @@ ProxyPass "/examples" "http://backend.ex
<directivesynopsis type="section">
<name>Proxy</name>
-<description>Conteneur de directives s'appliquant à des ressources
-mandatées</description>
+<description>Conteneur de directives s'appliquant à des ressources
+mandatées</description>
<syntax><Proxy <var>url-avec-jokers</var>> ...</Proxy></syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
- <p>Les directives situées dans une section <directive
+ <p>Les directives situées dans une section <directive
type="section">Proxy</directive> ne s'appliquent qu'au contenu
- mandaté concerné. Les jokers de style shell sont autorisés.</p>
+ mandaté concerné. Les jokers de style shell sont autorisés.</p>
- <p>Par exemple, les lignes suivantes n'autoriseront à accéder à un
- contenu via votre serveur mandataire que les hôtes appartenant à
+ <p>Par exemple, les lignes suivantes n'autoriseront à accéder à un
+ contenu via votre serveur mandataire que les hôtes appartenant à
<code>votre-reseau.example.com</code> :</p>
<highlight language="config">
@@ -543,10 +543,10 @@ mandatées</description>
</Proxy>
</highlight>
- <p>Dans l'exemple suivant, tous les fichiers du répertoire
- <code>foo</code> de <code>example.com</code> seront traités par le
- filtre <code>INCLUDES</code> lorsqu'ils seront envoyés par
- l'intermédiaire du serveur mandataire :</p>
+ <p>Dans l'exemple suivant, tous les fichiers du répertoire
+ <code>foo</code> de <code>example.com</code> seront traités par le
+ filtre <code>INCLUDES</code> lorsqu'ils seront envoyés par
+ l'intermédiaire du serveur mandataire :</p>
<highlight language="config">
<Proxy "http://example.com/foo/*">
@@ -554,19 +554,19 @@ mandatées</description>
</Proxy>
</highlight>
- <note><title>Différences avec la section de configuration Location</title>
- <p>Une URL d'arrière-plan sera concernée par le conteneur Proxy si
- elle commence par la <var>url-avec-jokers</var>, même si le
- dernier segment de chemin de la directive ne correspond qu'à un
- préfixe de segment dee chemin de l'URL d'arrière-plan. Par exemple, <Proxy
+ <note><title>Différences avec la section de configuration Location</title>
+ <p>Une URL d'arrière-plan sera concernée par le conteneur Proxy si
+ elle commence par la <var>url-avec-jokers</var>, même si le
+ dernier segment de chemin de la directive ne correspond qu'à un
+ préfixe de segment dee chemin de l'URL d'arrière-plan. Par exemple, <Proxy
"http://example.com/foo"> correspondra entre autres aux URLs
http://example.com/foo, http://example.com/foo/bar, et
http://example.com/foobar. La correspondance de l'URL finale
- diffère du comportement de la section <directive type="section"
+ diffère du comportement de la section <directive type="section"
module="core">Location</directive> qui, pour le cas de cette note,
traitera le segment de chemin final comme s'il se terminait par un
slash.</p>
- <p>Pour un contrôle plus fin de la correspondance des URL, voir la
+ <p>Pour un contrôle plus fin de la correspondance des URL, voir la
directive <directive type="section">ProxyMatch</directive>.</p>
</note>
@@ -576,8 +576,8 @@ mandatées</description>
<directivesynopsis>
<name>ProxyBadHeader</name>
-<description>Détermine la manière de traiter les lignes d'en-tête
-incorrectes d'une réponse</description>
+<description>Détermine la manière de traiter les lignes d'en-tête
+incorrectes d'une réponse</description>
<syntax>ProxyBadHeader IsError|Ignore|StartBody</syntax>
<default>ProxyBadHeader IsError</default>
<contextlist><context>server config</context><context>virtual host</context>
@@ -585,53 +585,53 @@ incorrectes d'une réponse</descri
<usage>
<p>La directive <directive>ProxyBadHeader</directive> permet de
- déterminer le comportement de <module>mod_proxy</module> lorsqu'il
- reçoit des lignes d'en-tête de réponse dont la syntaxe n'est pas valide (c'est
- à dire ne contenant pas de caractère ':') en provenance du serveur
+ déterminer le comportement de <module>mod_proxy</module> lorsqu'il
+ reçoit des lignes d'en-tête de réponse dont la syntaxe n'est pas valide (c'est
+ à dire ne contenant pas de caractère ':') en provenance du serveur
original. Les arguments disponibles sont :</p>
<dl>
<dt><code>IsError</code></dt>
- <dd>Annule la requête et renvoie une réponse de code 502 (mauvaise
- passerelle). C'est le comportement par défaut.</dd>
+ <dd>Annule la requête et renvoie une réponse de code 502 (mauvaise
+ passerelle). C'est le comportement par défaut.</dd>
<dt><code>Ignore</code></dt>
- <dd>Traite les lignes d'en-tête incorrectes comme si elles n'avaient
- pas été envoyées.</dd>
+ <dd>Traite les lignes d'en-tête incorrectes comme si elles n'avaient
+ pas été envoyées.</dd>
<dt><code>StartBody</code></dt>
- <dd>A la réception de la première ligne d'en-tête incorrecte, les
- autres en-têtes sont lus et ce qui reste est traité en tant que
- corps. Ceci facilite la prise en compte des serveurs d'arrière-plan
- bogués qui oublient d'insérer une ligne vide entre les
- en-têtes et le corps.</dd>
+ <dd>A la réception de la première ligne d'en-tête incorrecte, les
+ autres en-têtes sont lus et ce qui reste est traité en tant que
+ corps. Ceci facilite la prise en compte des serveurs d'arrière-plan
+ bogués qui oublient d'insérer une ligne vide entre les
+ en-têtes et le corps.</dd>
</dl>
</usage>
</directivesynopsis>
<directivesynopsis type="section">
<name>ProxyMatch</name>
-<description>Conteneur de directives s'appliquant à des ressources
-mandatées correspondant à une expression rationnelle</description>
+<description>Conteneur de directives s'appliquant à des ressources
+mandatées correspondant à une expression rationnelle</description>
<syntax><ProxyMatch <var>regex</var>> ...</ProxyMatch></syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p>La directive <directive type="section">ProxyMatch</directive> est
- identique à la directive <directive module="mod_proxy"
- type="section">Proxy</directive>, à l'exception qu'elle définit
+ identique à la directive <directive module="mod_proxy"
+ type="section">Proxy</directive>, à l'exception qu'elle définit
les URLs auxquelles elle s'applique en utilisant une <glossary
ref="regex">expression rationnelle</glossary>.</p>
- <p>A partir de la version 2.4.8, les groupes nommés et les
- références arrières sont extraits et enregistrés dans
- l'environnement avec leur nom en majuscules et préfixé par "MATCH_". Ceci permet
- de référencer des URLs dans des <a href="../expr.html">expressions</a>
+ <p>A partir de la version 2.4.8, les groupes nommés et les
+ références arrières sont extraits et enregistrés dans
+ l'environnement avec leur nom en majuscules et préfixé par "MATCH_". Ceci permet
+ de référencer des URLs dans des <a href="../expr.html">expressions</a>
ou au sein de modules comme <module>mod_rewrite</module>. Pour
- éviter toute confusion, les références arrières numérotées (non
- nommées) sont ignorées. Vous devez utiliser à la place des groupes
- nommés.</p>
+ éviter toute confusion, les références arrières numérotées (non
+ nommées) sont ignorées. Vous devez utiliser à la place des groupes
+ nommés.</p>
<highlight language="config">
<ProxyMatch "^http://(?<sitename>[^/]+)">
@@ -644,7 +644,7 @@ mandatées correspondant à
<directivesynopsis>
<name>ProxyPreserveHost</name>
-<description>Utilise l'en-tête de requête entrante Host pour la requête
+<description>Utilise l'en-tête de requête entrante Host pour la requête
du mandataire</description>
<syntax>ProxyPreserveHost On|Off</syntax>
<default>ProxyPreserveHost Off</default>
@@ -652,25 +652,25 @@ du mandataire</description>
<context>directory</context>
</contextlist>
<compatibility>Utilisable
-dans un contexte de répertoire depuis la version 2.3.3.</compatibility>
+dans un contexte de répertoire depuis la version 2.3.3.</compatibility>
<usage>
- <p>Lorsqu'elle est activée, cette directive va transmettre l'en-tête
- Host: de la requête entrante vers le serveur mandaté, au lieu du nom
- d'hôte spécifié par la directive <directive
+ <p>Lorsqu'elle est activée, cette directive va transmettre l'en-tête
+ Host: de la requête entrante vers le serveur mandaté, au lieu du nom
+ d'hôte spécifié par la directive <directive
module="mod_proxy">ProxyPass</directive>.</p>
- <p>Cette directive est habituellement définie à <code>Off</code>.
- Elle est principalement utile dans les configurations particulières
- comme l'hébergement virtuel mandaté en masse à base de nom, où
- l'en-tête Host d'origine doit être évalué par le serveur
- d'arrière-plan.</p>
+ <p>Cette directive est habituellement définie à <code>Off</code>.
+ Elle est principalement utile dans les configurations particulières
+ comme l'hébergement virtuel mandaté en masse à base de nom, où
+ l'en-tête Host d'origine doit être évalué par le serveur
+ d'arrière-plan.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyRequests</name>
-<description>Active la fonctionnalité (standard) de mandataire
+<description>Active la fonctionnalité (standard) de mandataire
direct</description>
<syntax>ProxyRequests On|Off</syntax>
<default>ProxyRequests Off</default>
@@ -678,29 +678,29 @@ direct</description>
</contextlist>
<usage>
- <p>Cette directive permet d'activer/désactiver la fonctionnalité de
- serveur mandataire direct d'Apache httpd. Définir ProxyRequests à
+ <p>Cette directive permet d'activer/désactiver la fonctionnalité de
+ serveur mandataire direct d'Apache httpd. Définir ProxyRequests à
<code>Off</code> n'interdit pas l'utilisation de la directive
<directive module="mod_proxy">ProxyPass</directive>.</p>
<p>Pour une configuration typique de mandataire inverse ou
- passerelle, cette directive doit être définie à
+ passerelle, cette directive doit être définie à
<code>Off</code>.</p>
- <p>Afin d'activer la fonctionnalité de mandataire pour des sites
+ <p>Afin d'activer la fonctionnalité de mandataire pour des sites
HTTP et/ou FTP, les modules <module>mod_proxy_http</module> et/ou
- <module>mod_proxy_ftp</module> doivent également être chargés dans le
+ <module>mod_proxy_ftp</module> doivent également être chargés dans le
serveur.</p>
- <p>Pour activer la fonctionnalité de mandataire sur les sites chiffrés en HTTPS, le module
- <module>mod_proxy_connect</module> doit également être chargé dans le serveur.</p>
+ <p>Pour activer la fonctionnalité de mandataire sur les sites chiffrés en HTTPS, le module
+ <module>mod_proxy_connect</module> doit également être chargé dans le serveur.</p>
<note type="warning"><title>Avertissement</title>
- <p>N'activez pas la fonctionnalité de mandataire avec la directive
+ <p>N'activez pas la fonctionnalité de mandataire avec la directive
<directive module="mod_proxy">ProxyRequests</directive> avant
- d'avoir <a href="#access">sécurisé votre serveur</a>. Les serveurs
+ d'avoir <a href="#access">sécurisé votre serveur</a>. Les serveurs
mandataires ouverts sont dangereux non seulement pour votre
- réseau, mais aussi pour l'Internet au sens large.</p>
+ réseau, mais aussi pour l'Internet au sens large.</p>
</note>
</usage>
<seealso><a href="#forwardreverse">Mandataires/Passerelles directs et
@@ -709,19 +709,19 @@ inverses</a></seealso>
<directivesynopsis>
<name>ProxyRemote</name>
-<description>Mandataire distant à utiliser pour traiter certaines
-requêtes</description>
+<description>Mandataire distant à utiliser pour traiter certaines
+requêtes</description>
<syntax>ProxyRemote <var>comparaison</var> <var>serveur-distant</var></syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
- <p>Cette directive permet de définir des mandataires distants pour
+ <p>Cette directive permet de définir des mandataires distants pour
ce mandataire. <var>comparaison</var> est soit le nom d'un protocole
que supporte le serveur distant, soit une URL partielle pour
- laquelle le serveur distant devra être utilisé, soit <code>*</code>
- pour indiquer que le serveur distant doit être utilisé pour toutes
- les requêtes. <var>serveur-distant</var> est une URL partielle
+ laquelle le serveur distant devra être utilisé, soit <code>*</code>
+ pour indiquer que le serveur distant doit être utilisé pour toutes
+ les requêtes. <var>serveur-distant</var> est une URL partielle
correspondant au serveur distant. Syntaxe : </p>
<example>
@@ -729,11 +729,11 @@ requêtes</description>
<var>protocole</var>://<var>nom-serveur</var>[:<var>port</var>]
</example>
- <p><var>protocole</var> est effectivement le protocole à utiliser
+ <p><var>protocole</var> est effectivement le protocole à utiliser
pour communiquer avec le serveur distant ; ce module ne supporte que
<code>http</code> et <code>https</code>. Lorsqu'on utilise
- <code>https</code>, les requêtes sont redirigées par le mandataire
- distant en utilisant la méthode HTTP CONNECT.</p>
+ <code>https</code>, les requêtes sont redirigées par le mandataire
+ distant en utilisant la méthode HTTP CONNECT.</p>
<example><title>Exemple</title>
<highlight language="config">
@@ -744,168 +744,168 @@ ProxyRemote "ftp" "http://ftpproxy.mydom
</highlight>
</example>
- <p>Dans la dernière ligne de l'exemple, le mandataire va faire
- suivre les requêtes FTP, encapsulées dans une autre requête mandatée
+ <p>Dans la dernière ligne de l'exemple, le mandataire va faire
+ suivre les requêtes FTP, encapsulées dans une autre requête mandatée
HTTP, vers un autre mandataire capable de les traiter.</p>
<p>Cette directive supporte aussi les configurations de mandataire
- inverse ; un serveur web d'arrière-plan peut être intégré dans
- l'espace d'URL d'un serveur virtuel, même si ce serveur est caché
+ inverse ; un serveur web d'arrière-plan peut être intégré dans
+ l'espace d'URL d'un serveur virtuel, même si ce serveur est caché
par un autre mandataire direct.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyRemoteMatch</name>
-<description>Le mandataire distant à utiliser pour traiter les requêtes
-correspondant à une expression rationnelle</description>
+<description>Le mandataire distant à utiliser pour traiter les requêtes
+correspondant à une expression rationnelle</description>
<syntax>ProxyRemoteMatch <var>regex</var> <var>serveur-distant</var></syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p>La directive <directive>ProxyRemoteMatch</directive> est
- identique à la directive <directive
- module="mod_proxy">ProxyRemote</directive>, à l'exception du
+ identique à la directive <directive
+ module="mod_proxy">ProxyRemote</directive>, à l'exception du
premier argument qui est une <glossary ref="regex">expression
- rationnelle</glossary> à mettre en correspondance avec l'URL de la
- requête.</p>
+ rationnelle</glossary> à mettre en correspondance avec l'URL de la
+ requête.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>BalancerGrowth</name>
-<description>Nombre de membres supplémentaires pouvant être ajoutés
-après la configuration initiale</description>
+<description>Nombre de membres supplémentaires pouvant être ajoutés
+après la configuration initiale</description>
<syntax>BalancerGrowth <var>#</var></syntax>
<default>BalancerGrowth 5</default>
<contextlist><context>server config</context><context>virtual host</context></contextlist>
<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 membres pouvant
- ê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>Cette directive permet de définir le nombre de membres pouvant
+ ê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>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>BalancerPersist</name>
- <description>Tente de conserver les changements effectués par le
- gestionnaire de répartition de charge après un redémarrage du
+ <description>Tente de conserver les changements effectués par le
+ gestionnaire de répartition de charge après un redémarrage du
serveur.</description>
<syntax>BalancerPersist On|Off</syntax>
<default>BalancerPersist Off</default>
<contextlist><context>server config</context><context>virtual host</context></contextlist>
- <compatibility>BalancerPersist n'est disponible qu'à partir de la
+ <compatibility>BalancerPersist n'est disponible qu'à partir de la
version 2.4.4 du serveur HTTP Apache.</compatibility>
<usage>
<p>Cette directive permet de conserver le contenu de l'espace
- mémoire partagé associé aux répartiteurs de charge et à leurs
- membres après un redémarrage du serveur. Ces modifications
- locales ne sont ainsi pas perdues lors des transitions d'état
- dues à un redémarrage.</p>
+ mémoire partagé associé aux répartiteurs de charge et à leurs
+ membres après un redémarrage du serveur. Ces modifications
+ locales ne sont ainsi pas perdues lors des transitions d'état
+ dues à un redémarrage.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxyPassInherit</name>
- <description>Héritage des directives ProxyPass définies au niveau du
+ <description>Héritage des directives ProxyPass définies au niveau du
serveur principal</description>
<syntax>ProxyPassInherit On|Off</syntax>
<default>ProxyPassInherit On</default>
<contextlist><context>server config</context><context>virtual host</context></contextlist>
- <compatibility>Disponible à partir de la version 2.4.5 du serveur
+ <compatibility>Disponible à partir de la version 2.4.5 du serveur
HTTP Apache.</compatibility>
<usage>
- <p>Cette directive permet à un serveur virtuel d'hériter des
- directives <directive module="mod_proxy">ProxyPass</directive> définies
- au niveau du serveur principal. Si vous utilisez la fonctionnalité de
+ <p>Cette directive permet à un serveur virtuel d'hériter des
+ directives <directive module="mod_proxy">ProxyPass</directive> définies
+ au niveau du serveur principal. Si vous utilisez la fonctionnalité de
modifications dynamiques du Balancer Manager, cette directive peut
- causer des problèmes et des comportements inattendus et doit donc
- être désactivée.</p>
- <p>Les valeurs définies au niveau du serveur principal
- constituent les valeurs par défaut pour tous les serveurs virtuels.</p>
- <p>La désactivation de ProxyPassInherit désactive aussi la
+ causer des problèmes et des comportements inattendus et doit donc
+ être désactivée.</p>
+ <p>Les valeurs définies au niveau du serveur principal
+ constituent les valeurs par défaut pour tous les serveurs virtuels.</p>
+ <p>La désactivation de ProxyPassInherit désactive aussi la
directive <directive module="mod_proxy">BalancerInherit</directive>.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>BalancerInherit</name>
- <description>Héritage des membres du groupes de répartition de
- charge du mandataire définis au niveau du serveur principal</description>
+ <description>Héritage des membres du groupes de répartition de
+ charge du mandataire définis au niveau du serveur principal</description>
<syntax>BalancerInherit On|Off</syntax>
<default>BalancerInherit On</default>
<contextlist><context>server config</context><context>virtual host</context></contextlist>
- <compatibility>Disponible à partir de la version 2.4.5 du serveur
+ <compatibility>Disponible à partir de la version 2.4.5 du serveur
HTTP Apache.</compatibility>
<usage>
<p>Cette directive permet d'attribuer au serveur virtuel courant
- l'héritage des membres de groupes de répartition de charge
- définis au niveau du serveur
- principal. Elle ne doit pas être activée si vous
- utilisez la fonctionnalité de modifications dynamiques du
- gestionnaire de répartition de charge (Balancer Manager) pour
- éviter des problèmes et des comportements inattendus.</p>
- <p>Les définitions au niveau du serveur principal constituent
- les définitions par défaut au niveau des serveurs virtuels.</p>
+ l'héritage des membres de groupes de répartition de charge
+ définis au niveau du serveur
+ principal. Elle ne doit pas être activée si vous
+ utilisez la fonctionnalité de modifications dynamiques du
+ gestionnaire de répartition de charge (Balancer Manager) pour
+ éviter des problèmes et des comportements inattendus.</p>
+ <p>Les définitions au niveau du serveur principal constituent
+ les définitions par défaut au niveau des serveurs virtuels.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>BalancerMember</name>
-<description>Ajoute un membre à un groupe de répartition de
+<description>Ajoute un membre à un groupe de répartition de
charge</description>
<syntax>BalancerMember [<var>balancerurl</var>] <var>url</var> [<var
- >clé=valeur [clé=valeur ...]]</var></syntax>
+ >clé=valeur [clé=valeur ...]]</var></syntax>
<contextlist><context>directory</context>
</contextlist>
<compatibility>Disponible depuis la version 2.2 du serveur HTTP Apache.</compatibility>
<usage>
- <p>Cette directive permet d'ajouter un membre à un groupe de
- répartition de charge. Elle peut se trouver dans un conteneur
+ <p>Cette directive permet d'ajouter un membre à un groupe de
+ répartition de charge. Elle peut se trouver dans un conteneur
<code><Proxy <var>balancer://</var>...></code>, et accepte
- tous les paramètres de paires clé/valeur que supporte la directive
+ tous les paramètres de paires clé/valeur que supporte la directive
<directive module="mod_proxy">ProxyPass</directive>.</p>
- <p>La directive <directive>BalancerMember</directive> accepte un paramètre
- supplémentaire : <var>loadfactor</var>. Il s'agit du facteur de
- charge du membre - un nombre entre 1 (valeur par défaut) et 100, qui
- définit la charge à appliquer au membre en question.</p>
+ <p>La directive <directive>BalancerMember</directive> accepte un paramètre
+ supplémentaire : <var>loadfactor</var>. Il s'agit du facteur de
+ charge du membre - un nombre entre 1 (valeur par défaut) et 100, qui
+ définit la charge à appliquer au membre en question.</p>
<p>L'argument <var>balancerurl</var> n'est requis que s'il ne se trouve pas
- dèjà dans la directive de conteneur <code><Proxy
- <var>balancer://</var>...></code>. Il correspond à l'URL d'un
- répartiteur de charge défini par une directive <directive
+ dèjà dans la directive de conteneur <code><Proxy
+ <var>balancer://</var>...></code>. Il correspond à l'URL d'un
+ répartiteur de charge défini par une directive <directive
module="mod_proxy">ProxyPass</directive>.</p>
- <p>La partie chemin de l'URL du répartiteur dans toute directive de
+ <p>La partie chemin de l'URL du répartiteur dans toute directive de
conteneur <code><Proxy <var>balancer://</var>...></code> est
- ignorée.</p>
+ ignorée.</p>
<p>En particulier, le slash de fin de l'URL d'un
- <directive>BalancerMember</directive> doit être supprimé.</p>
+ <directive>BalancerMember</directive> doit être supprimé.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>ProxySet</name>
-<description>Définit différents paramètres relatifs à la répartition de
-charge des mandataires et aux membres des groupes de répartition de
+<description>Définit différents paramètres relatifs à la répartition de
+charge des mandataires et aux membres des groupes de répartition de
charge</description>
-<syntax>ProxySet <var>url</var> <var>clé=valeur [clé=valeur ...]</var></syntax>
+<syntax>ProxySet <var>url</var> <var>clé=valeur [clé=valeur ...]</var></syntax>
<contextlist><context>directory</context>
</contextlist>
<compatibility>ProxySet n'est disponible que depuis la version 2.2
du serveur HTTP Apache.</compatibility>
<usage>
- <p>Cette directive propose une méthode alternative pour définir tout
- paramètre relatif aux répartiteurs de charge et serveurs cibles de
- mandataires normalement définis via la directive <directive
+ <p>Cette directive propose une méthode alternative pour définir tout
+ paramètre relatif aux répartiteurs de charge et serveurs cibles de
+ mandataires normalement définis via la directive <directive
module="mod_proxy">ProxyPass</directive>. Si elle se trouve dans un
- conteneur <code><Proxy <var>url de répartiteur|url de
+ conteneur <code><Proxy <var>url de répartiteur|url de
serveur cible</var>></code>, l'argument <var>url</var> n'est pas
- nécessaire. Comme effet de bord, le répartiteur ou serveur cible respectif
- est créé. Ceci peut s'avérer utile pour la mise en oeuvre d'un
+ nécessaire. Comme effet de bord, le répartiteur ou serveur cible respectif
+ est créé. Ceci peut s'avérer utile pour la mise en oeuvre d'un
mandataire inverse via une directive <directive
module="mod_rewrite">RewriteRule</directive> au lieu de <directive
module="mod_proxy">ProxyPass</directive>.</p>
@@ -935,10 +935,10 @@ du serveur HTTP Apache.</compatibility>
</highlight>
<note type="warning"><title>Avertissement</title>
- <p>Gardez à l'esprit qu'une même clé de paramètre peut avoir
- différentes significations selon qu'elle s'applique à un
- répartiteur ou à un serveur cible, et ceci est illustré par les deux
- exemples précédents où il est question d'un timeout.</p>
+ <p>Gardez à l'esprit qu'une même clé de paramètre peut avoir
+ différentes significations selon qu'elle s'applique à un
+ répartiteur ou à un serveur cible, et ceci est illustré par les deux
+ exemples précédents où il est question d'un timeout.</p>
</note>
</usage>
@@ -946,58 +946,58 @@ du serveur HTTP Apache.</compatibility>
<directivesynopsis>
<name>ProxyPass</name>
-<description>Référencer des serveurs distants depuis
+<description>Référencer des serveurs distants depuis
l'espace d'URLs du serveur local</description>
-<syntax>ProxyPass [<var>chemin</var>] !|<var>url</var> [<var>clé=valeur</var>
- <var>[clé=valeur</var> ...]] [nocanon] [interpolate] [noquery]</syntax>
+<syntax>ProxyPass [<var>chemin</var>] !|<var>url</var> [<var>clé=valeur</var>
+ <var>[clé=valeur</var> ...]] [nocanon] [interpolate] [noquery]</syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context>
</contextlist>
<compatibility>Les sockets de style Unix (Unix Domain Socket - UDS)
-sont supportés à partir de la version 2.4.7 du serveur HTTP Apache</compatibility>
+sont supportés à partir de la version 2.4.7 du serveur HTTP Apache</compatibility>
<usage>
- <p>Cette directive permet de référencer des serveurs distants depuis
+ <p>Cette directive permet de référencer des serveurs distants depuis
l'espace d'URLs du serveur local. Le serveur
local n'agit pas en tant que mandataire au sens conventionnel, mais
- plutôt comme miroir du serveur distant. Le serveur local est
- souvent nommé <dfn>mandataire inverse</dfn> ou
+ plutôt comme miroir du serveur distant. Le serveur local est
+ souvent nommé <dfn>mandataire inverse</dfn> ou
<dfn>passerelle</dfn>. L'argument <var>chemin</var> est le nom d'un
chemin virtuel local ; <var>url</var> est une URL partielle pour le
- serveur distant et ne doit pas contenir de chaîne d'arguments.</p>
+ serveur distant et ne doit pas contenir de chaîne d'arguments.</p>
- <note><strong>Note : </strong>Cette directive ne peut pas être
- utilisée dans un contexte de niveau répertoire.</note>
+ <note><strong>Note : </strong>Cette directive ne peut pas être
+ utilisée dans un contexte de niveau répertoire.</note>
- <note type="warning">En général, la directive <directive
- module="mod_proxy">ProxyRequests</directive> doit être définie à
+ <note type="warning">En général, la directive <directive
+ module="mod_proxy">ProxyRequests</directive> doit être définie à
<strong>off</strong> lorsqu'on utilise la directive
<directive>ProxyPass</directive>.</note>
- <p>Les sockets de style Unix sont supportés à partir de la version
- 2.4.7 du serveur HTTP Apache ; pour utiliser cette fonctionnalité,
- il suffit d'utiliser une URL cible préfixée par
+ <p>Les sockets de style Unix sont supportés à partir de la version
+ 2.4.7 du serveur HTTP Apache ; pour utiliser cette fonctionnalité,
+ il suffit d'utiliser une URL cible préfixée par
<code>unix:/path/lis.sock|</code>. Par exemple, pour mandater HTTP
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><strong>Note :</strong>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
+ <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
+ 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
+ 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
+ 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>
+ module="core">Location</directive> séparée.</p>
<p>Supposons que le serveur local a pour adresse
<code>http://example.com/</code> ; alors la ligne</p>
@@ -1008,23 +1008,23 @@ sont supportés à partir de
</Location>
</highlight>
- <p>va convertir en interne toute requête pour
- <code>http://example.com/miroir/foo/bar</code> en une requête
- mandatée pour <code>http://backend.example.com/bar</code>.</p>
+ <p>va convertir en interne toute requête pour
+ <code>http://example.com/miroir/foo/bar</code> en une requête
+ mandatée pour <code>http://backend.example.com/bar</code>.</p>
- <p>La directive ProxyPass ne peut pas être placée dans une section
+ <p>La directive ProxyPass ne peut pas être placée dans une section
<directive type="section" module="core">Directory</directive> ou
<directive type="section" module="core">Files</directive>.</p>
<p>Si vous avez besoin d'un configuration de mandataire inverse plus
- souple, reportez-vous à la documentaion de la directive <directive
+ souple, reportez-vous à la documentaion de la directive <directive
module="mod_rewrite">RewriteRule</directive> et son drapeau
<code>[P]</code>.</p>
<p>La syntaxe alternative suivante est valide, bien qu'elle puisse
- induire une dégradation des performances lorsqu'elle est
- présente en très grand nombre. Elle possède l'avantage de
- permettre un contrôle dynamique via l'interface <a
+ induire une dégradation des performances lorsqu'elle est
+ présente en très grand nombre. Elle possède l'avantage de
+ permettre un contrôle dynamique via l'interface <a
href="mod_proxy_balancer.html#balancer_manager">Balancer Manager</a> :</p>
<highlight language="config">
@@ -1033,14 +1033,14 @@ sont supportés à partir de
<note type="warning">
<p>Si le premier argument se termine par un slash
- <strong>/</strong>, il doit en être de même pour le second argument
+ <strong>/</strong>, il doit en être de même pour le second argument
et vice versa. Dans le cas contraire, il risque de manquer des
- slashes nécessaires dans la requête résultante vers le serveur
- d'arrière-plan et les résulats ne seront pas ceux attendus.
+ slashes nécessaires dans la requête résultante vers le serveur
+ d'arrière-plan et les résulats ne seront pas ceux attendus.
</p>
</note>
- <p>Le drapeau <code>!</code> permet de soustraire un sous-répertoire
+ <p>Le drapeau <code>!</code> permet de soustraire un sous-répertoire
du mandat inverse, comme dans l'exemple suivant :</p>
<highlight language="config">
@@ -1057,60 +1057,60 @@ ProxyPass "/mirror/foo/i" "!"
ProxyPass "/mirror/foo" "http://backend.example.com"
</highlight>
- <p>va mandater toutes les requêtes pour <code>/miroir/foo</code>
- vers <code>backend.example.com</code>, <em>sauf</em> les requêtes
+ <p>va mandater toutes les requêtes pour <code>/miroir/foo</code>
+ vers <code>backend.example.com</code>, <em>sauf</em> les requêtes
pour <code>/miroir/foo/i</code>.</p>
<note type="warning"><title>Ordre de classement des directives ProxyPass</title>
<p>Les directives <directive
module="mod_proxy">ProxyPass</directive> et <directive
- module="mod_proxy">ProxyPassMatch</directive> sont évaluées dans
+ module="mod_proxy">ProxyPassMatch</directive> sont évaluées dans
l'ordre de leur apparition dans le fichier de configuration. La
- première règle qui correspond s'applique. Vous devez donc en
- général classer les règles <directive
+ première règle qui correspond s'applique. Vous devez donc en
+ général classer les règles <directive
module="mod_proxy">ProxyPass</directive> qui entrent en conflit de
- l'URL la plus longue à la plus courte. Dans le cas contraire, les
- 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
+ l'URL la plus longue à la plus courte. Dans le cas contraire, les
+ 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. Par contre, 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>
+ la plus spécifique qui l'emportera.</p>
- <p>Pour les mêmes raisons, les exclusions doivent se situer
+ <p>Pour les mêmes raisons, les exclusions doivent se situer
<em>avant</em> les directives <directive>ProxyPass</directive>
- générales.</p>
+ générales.</p>
</note> <!-- /ordering_proxypass -->
- <p><strong>ProxyPass <code>clé=valeur</code> Paramètres</strong></p>
+ <p><strong>ProxyPass <code>clé=valeur</code> Paramètres</strong></p>
<p>Depuis la version 2.1 du serveur HTTP Apache, mod_proxy supporte
- les groupements de connexions vers un serveur d'arrière-plan. Les
- connexions créées à la demande peuvent être enregistrées dans un
- groupement pour une utilisation ultérieure. La taille du groupe
- ainsi que d'autres caractéristiques peuvent être définies via la
- directive <directive>ProxyPass</directive> au moyen de paramètres
- <code>clé=valeur</code> dont la description fait l'objet des
+ les groupements de connexions vers un serveur d'arrière-plan. Les
+ connexions créées à la demande peuvent être enregistrées dans un
+ groupement pour une utilisation ultérieure. La taille du groupe
+ ainsi que d'autres caractéristiques peuvent être définies via la
+ directive <directive>ProxyPass</directive> au moyen de paramètres
+ <code>clé=valeur</code> dont la description fait l'objet des
tableaux ci-dessous.</p>
- <p>Par défaut, mod_proxy permet et met en réserve le nombre maximum
- de connexions pouvant être utilisées simultanément par le processus
- enfant concerné du serveur web. Le paramètre <code>max</code> permet
- de réduire cette valeur par défaut. 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 moins
- <code>ttl</code> secondes seront fermées. <code>ttl</code> permet
- aussi d'empêcher l'utilisation d'une connexion susceptible d'être
- fermée suite à une fin de vie de connexion persistante sur le
- serveur d'arrière-plan.</p>
+ <p>Par défaut, mod_proxy permet et met en réserve le nombre maximum
+ de connexions pouvant être utilisées simultanément par le processus
+ enfant concerné du serveur web. Le paramètre <code>max</code> permet
+ de réduire cette valeur par défaut. 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 moins
+ <code>ttl</code> secondes seront fermées. <code>ttl</code> permet
+ aussi d'empêcher l'utilisation d'une connexion susceptible d'être
+ fermée suite à une fin de vie de connexion persistante sur le
+ serveur d'arrière-plan.</p>
<p>Le groupement de connexions est maintenu au niveau de chaque
processus enfant du serveur web, et <code>max</code>, ainsi que les
- autres paramètres, ne font
- l'objet d'aucune coordination entre les différents processus
- enfants, sauf si un seul processus enfant est autorisé par la
+ autres paramètres, ne font
+ l'objet d'aucune coordination entre les différents processus
+ enfants, sauf si un seul processus enfant est autorisé par la
configuration ou la conception du module multi-processus (MPM).</p>
<example><title>Exemple</title>
@@ -1119,212 +1119,212 @@ ProxyPass "/mirror/foo" "http://backend.
</highlight>
</example>
- <table border="2"><tr><th>Paramètres de BalancerMember</th></tr></table>
+ <table border="2"><tr><th>Paramètres de BalancerMember</th></tr></table>
<table>
- <tr><th>Paramètre</th>
- <th>Défaut</th>
+ <tr><th>Paramètre</th>
+ <th>Défaut</th>
<th>Description</th></tr>
<tr><td>min</td>
<td>0</td>
- <td>Nombre minimum d'entrées dans le pool de connexions,
- distinct du nombre de connexions effectif. La valeur par défaut
- ne doit être modifiée que dans des circonstances particulières
- où la mémoire associée aux connexions avec le serveur
- d'arrière-plan doit être préallouée ou réservée dans le tas.</td></tr>
+ <td>Nombre minimum d'entrées dans le pool de connexions,
+ distinct du nombre de connexions effectif. La valeur par défaut
+ ne doit être modifiée que dans des circonstances particulières
+ où la mémoire associée aux connexions avec le serveur
+ d'arrière-plan doit être préallouée ou réservée dans le tas.</td></tr>
<tr><td>max</td>
<td>1...n</td>
- <td>Nombre maximum de connexions autorisées vers le serveur
- d'arrière-plan. La valeur par défaut correspond au nombre de
+ <td>Nombre maximum de connexions autorisées vers le serveur
+ d'arrière-plan. La valeur par défaut correspond au nombre de
threads par processus pour le MPM (Module Multi Processus)
actif. La valeur sera toujours 1 pour le MPM Prefork, alors
- qu'elle dépendra de la définition de la directive
+ qu'elle dépendra de la définition de la directive
<directive>ThreadsPerChild</directive> pour les autres MPMs.</td></tr>
<tr><td>smax</td>
<td>max</td>
- <td>Les entrées du pool de connexions conservées au delà de
- cette limite sont libérées au cours de certaines opérations si
- elles n'ont pas été utilisées au cours de leur durée de vie,
- définie par le paramètre <code>ttl</code>. Si l'entrée du pool
- de connexions est associée à une connexion, cette dernière sera
- fermée. La valeur par défaut ne doit être modifiée que dans des
- circonstances particulières où les entrées du pool de connexions
- et toutes connexions associées qui ont dépassé leur durée de vie
- doivent être libérées ou fermées de manière plus autoritaire.</td></tr>
+ <td>Les entrées du pool de connexions conservées au delà de
+ cette limite sont libérées au cours de certaines opérations si
+ elles n'ont pas été utilisées au cours de leur durée de vie,
+ définie par le paramètre <code>ttl</code>. Si l'entrée du pool
+ de connexions est associée à une connexion, cette dernière sera
+ fermée. La valeur par défaut ne doit être modifiée que dans des
+ circonstances particulières où les entrées du pool de connexions
+ et toutes connexions associées qui ont dépassé leur durée de vie
+ doivent être libérées ou fermées de manière plus autoritaire.</td></tr>
<tr><td>acquire</td>
<td>-</td>
- <td>Cette clé permet de définir le délai maximum d'attente pour
+ <td>Cette clé permet de définir le délai maximum d'attente pour
une connexion libre dans le jeu de connexions, en millisecondes.
S'il n'y a pas de connexion libre dans le jeu, Apache httpd renverra
- l'état <code>SERVER_BUSY</code> au client.
+ l'état <code>SERVER_BUSY</code> au client.
</td></tr>
<tr><td>connectiontimeout</td>
<td>timeout</td>
- <td>Délai d'attente d'une connexion en secondes.
- La durée en secondes pendant laquelle Apache httpd va attendre pour
- l'établissement d'une connexion vers le serveur d'arrière-plan.
- Le délai peut être spécifié en millisecondes en ajoutant le
+ <td>Délai d'attente d'une connexion en secondes.
+ La durée en secondes pendant laquelle Apache httpd va attendre pour
+ l'établissement d'une connexion vers le serveur d'arrière-plan.
+ Le délai peut être spécifié en millisecondes en ajoutant le
suffixe ms.
</td></tr>
<tr><td>disablereuse</td>
<td>Off</td>
- <td>Vous pouvez utiliser cette clé pour forcer mod_proxy à
- fermer immédiatement une connexion vers le serveur
- d'arrière-plan après utilisation, et ainsi désactiver le jeu de
- connexions permanentes vers ce serveur. Ceci peut s'avérer utile
- dans des situations où un pare-feu situé entre Apache httpd et le
- serveur d'arrière-plan (quelque soit le protocole) interrompt
- des connexions de manière silencieuse, ou lorsque le serveur
- d'arrière-plan lui-même est accessible par rotation de DNS
- (round-robin DNS). Pour désactiver la réutilisation du jeu de
- connexions, définissez cette clé à <code>On</code>.
+ <td>Vous pouvez utiliser cette clé pour forcer mod_proxy à
+ fermer immédiatement une connexion vers le serveur
+ d'arrière-plan après utilisation, et ainsi désactiver le jeu de
+ connexions permanentes vers ce serveur. Ceci peut s'avérer utile
+ dans des situations où un pare-feu situé entre Apache httpd et le
+ serveur d'arrière-plan (quelque soit le protocole) interrompt
+ des connexions de manière silencieuse, ou lorsque le serveur
+ d'arrière-plan lui-même est accessible par rotation de DNS
+ (round-robin DNS). Pour désactiver la réutilisation du jeu de
+ connexions, définissez cette clé à <code>On</code>.
</td></tr>
<tr><td>enablereuse</td>
<td>On</td>
- <td>Ce paramètre est utilisé par les gestionnaires de protocole pour
- lesquels la réutilisation des connexions est optionnelle (comme
+ <td>Ce paramètre est utilisé par les gestionnaires de protocole pour
+ lesquels la réutilisation des connexions est optionnelle (comme
<module>mod_proxy_fcgi</module>). C'est le contraire du
- paramètre 'disablereuse' ci-dessus, et il est supporté par les
- versions 2.4.11 et supérieures du serveur HTTP Apache.
+ paramètre 'disablereuse' ci-dessus, et il est supporté par les
+ versions 2.4.11 et supérieures du serveur HTTP Apache.
</td></tr>
<tr><td>flushpackets</td>
<td>off</td>
- <td>Permet de définir si le module mandataire doit vider
- automatiquement le tampon de sortie après chaque tronçon de
- données. 'off' signifie que le tampon sera vidé si
- nécessaire ;
- 'on' signifie que le tampon sera vidé après chaque envoi d'un
- tronçon de données, et 'auto' que le tampon sera vidé après un
- délai de 'flushwait' millisecondes si aucune entrée n'est reçue.
- Actuellement, cette clé n'est supportée que par AJP.
+ <td>Permet de définir si le module mandataire doit vider
+ automatiquement le tampon de sortie après chaque tronçon de
+ données. 'off' signifie que le tampon sera vidé si
+ nécessaire ;
+ 'on' signifie que le tampon sera vidé après chaque envoi d'un
+ tronçon de données, et 'auto' que le tampon sera vidé après un
+ délai de 'flushwait' millisecondes si aucune entrée n'est reçue.
[... 1395 lines stripped ...]