Serveur HTTP Apache Version 2.4 (original) (raw)

Module Apache mod_proxy

Langues Disponibles: en | fr | ja

Sommaire

Avertissement

N'activez pas la fonctionnalité de mandataire avec la directive[ProxyRequests](#proxyrequests) avant d'avoir sécurisé votre serveur. Les serveurs mandataires ouverts sont dangereux pour votre réseau, mais aussi pour l'Internet au sens large.

[mod_proxy](../mod/mod%5Fproxy.html) 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 modules tiers.

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[LoadModule](../mod/mod%5Fso.html#loadmodule). Ce jeu de module doit comporter :

• [mod_proxy](../mod/mod%5Fproxy.html), qui fournit les fonctionnalités de base d'un mandataire
• [mod_proxy_balancer](../mod/mod%5Fproxy%5Fbalancer.html) et un ou plusieurs modules de répartition, si la répartition de charge doit être mise en oeuvre (Voir la documentation de[mod_proxy_balancer](../mod/mod%5Fproxy%5Fbalancer.html) pour plus de détails).
• un ou plusieurs modules de types de mandataire, ou protocoles :

  Protocole	Module
  AJP13 (Protocole Apache JServe version 1.3)	mod_proxy_ajp
  CONNECT (pour SSL)	mod_proxy_connect
  FastCGI	mod_proxy_fcgi
  ftp	mod_proxy_ftp
  HTTP/0.9, HTTP/1.0, et HTTP/1.1	mod_proxy_http
  HTTP/2.0	mod_proxy_http2
  SCGI	mod_proxy_scgi
  UWSGI	mod_proxy_uwsgi
  WS and WSS (Web-sockets)	mod_proxy_wstunnel

En outre, d'autres modules fournissent des fonctionnalités étendues. [mod_cache](../mod/mod%5Fcache.html) et ses modules associés fournissent la mise en cache. Les directives SSLProxy* du module [mod_ssl](../mod/mod%5Fssl.html) 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.

Mandataires directs et mandataires/passerelles inverses

Le serveur HTTP Apache peut être configuré dans les deux modes mandatairedirect et mandataire inverse (aussi nommé mode passerelle).

Un mandataire direct standard est un serveur intermédiaire qui s'intercale entre le client et le serveur demandé. 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.

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 [mod_cache](../mod/mod%5Fcache.html)) pour réduire la charge du réseau.

La fonctionnalité de mandataire direct est activée via la directive [ProxyRequests](#proxyrequests). 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 sécuriser votre serveur de façon à ce que seuls les clients autorisés puissent accéder à votre serveur avant d'activer la fonctionnalité de mandataire direct.

Un mandataire inverse (ou passerelle), 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.

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.

La fonctionnalité de mandataire inverse est activée via la directive [ProxyPass](#proxypass) ou le drapeau [P] de la directive [RewriteRule](../mod/mod%5Frewrite.html#rewriterule). Il n'estpas nécessaire de définir [ProxyRequests](#proxyrequests) pour configurer un mandataire inverse.

Exemples simples

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.

Si en outre, vous désirez activer la mise en cache, consultez la documentation de [mod_cache](../mod/mod%5Fcache.html).

Mandataire inverse

ProxyPass "/foo" "http://foo.example.com/bar" ProxyPassReverse "/foo" "http://foo.example.com/bar"

Mandataire direct

ProxyRequests On ProxyVia On

<Proxy "*"> Require host internal.example.com

Accès via un gestionnaire

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 :

Scripts PHP et mandataire inverse

<FilesMatch ".php$"> # 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/"

Cette fonctionnalité est disponible à partir de la version 2.4.10 du serveur HTTP Apache.

Workers

Le mandataire gère la configuration et les paramètres de communication des serveurs originaux au sein d'objets nommésworkers. 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.

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 ne réutilisent pas les connexions et n'utilisent pas les connexions HTTP persistantes (Keep-Alive). En effet, les connexions TCP vers le serveur original sont fermées et ouvertes pour chaque requête.

Les workers définis explicitement sont identifiés par leur URL. Ils sont en général définis via les directives [ProxyPass](#proxypass) ou [ProxyPassMatch](#proxypassmatch) lorsqu'on les utilise dans le cadre d'un mandataire inverse :

ProxyPass "/example" "http://backend.example.com" connectiontimeout=5 timeout=30

Cette directive va créer un worker associé à l'URL du serveur original http://backend.example.com 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 directive [ProxySet](#proxyset),

ProxySet "http://backend.example.com" connectiontimeout=5 timeout=30

ou encore via les directives [Proxy](#proxy) et [ProxySet](#proxyset) :

<Proxy "" title="undefined" rel="noopener noreferrer">http://backend.example.com"> ProxySet connectiontimeout=5 timeout=30

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 [ProxyPass](#proxypass) 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.

L'URL qui identifie un worker correspond à l'URL de son serveur original, y compris un éventuel chemin donné :

ProxyPass "/examples" "http://backend.example.com/examples" ProxyPass "/docs" "http://backend.example.com/docs"

Dans cet exemple, deux workers différents sont définis, chacun d'eux utilisant des configurations et jeux de connexions séparés.

Partage de workers

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 dans le fichier de configuration. Dans l'exemple suivant,

ProxyPass "/apps" "http://backend.example.com/" timeout=60 ProxyPass "/examples" "http://backend.example.com/examples" timeout=10

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 qu'avertissement. Ainsi, dans l'exemple ci-dessus, la valeur de timeout retenue pour l'URL /exemples sera60, et non 10 !

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[ProxyPass](#proxypass).

Les workers définis explicitement sont de deux sortes :workers directs et workers de répartition (de charge). Ils supportent de nombreux attributs de configuration importants décrits dans la directive [ProxyPass](#proxypass). Ces mêmes attributs peuvent aussi être définis via la directive [ProxySet](#proxyset).

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 ajp, fcgi,ftp, http et scgi.

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.

Un worker de répartition est créé si son URL de worker comportebalancer comme indicateur de protocole. L'URL du répartiteur permet d'identifier de manière unique le worker de répartition. La directive [BalancerMember](#balancermember) permet d'ajouter des membres au répartiteur.

Résolution DNS pour les domaines originaux

La résolution DNS s'effectue lorsque le socket vers le domaine original est créé pour la première fois. Lorsque la réutilisation des connexions est activée, chaque domaine d'arrière-plan n'est résolu qu'une seule fois pour chaque processus enfant, et cette résolution est mise en cache pour toutes les connexions ultérieures jusqu'à ce que le processus enfant soit recyclé. Ce comportement doit être pris en considération lorsqu'on planifie des tâches de maintenance du DNS impactant les domaines d'arrière-plan. Veuillez aussi vous reporter aux paramètres de la directive [ProxyPass](#proxypass) pour plus de détails à propos de la réutilisation des connexions.

Contrôler l'accès à votre mandataire

Vous pouvez restreindre l'accès à votre mandataire via le bloc de contrôle [<Proxy>](#proxy) comme dans l'exemple suivant :

<Proxy "*"> Require ip 192.168.0

Pour plus de détails sur les directives de contrôle d'accès, voir la documentation du module[mod_authz_host](../mod/mod%5Fauthz%5Fhost.html).

Restreindre l'accès de manière stricte est essentiel si vous mettez en oeuvre un mandataire direct (en définissant la directive[ProxyRequests](#proxyrequests) à "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 [ProxyPass](#proxypass) avec ProxyRequests Off), le contrôle d'accès est moins critique car les clients ne peuvent contacter que les serveurs que vous avez spécifiés.

Voir aussi la variable d'environnement Proxy-Chain-Auth.

Ralentissement au démarrage

Si vous utilisez la directive [ProxyBlock](#proxyblock), 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.

Mandataire en Intranet

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 [ProxyRemote](#proxyremote) de façon à ce qu'elle fasse suivre le protocole 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[NoProxy](#noproxy) permet de spécifier quels hôtes appartiennent à l'Intranet et peuvent donc être accédés directement.

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 dehttp://un-serveur.example.com/. Certains serveurs mandataires commerciaux acceptent ce genre de requête et les traitent simplement en utilisant un nom de domaine local implicite. Lorsque la directive [ProxyDomain](#proxydomain) est utilisée et si le serveur est configuré comme mandataire, 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 fichier des marque-pages de l'utilisateur contiendra alors des noms de serveurs entièrement qualifiés.

Ajustements relatifs au protocole

Pour les cas où [mod_proxy](../mod/mod%5Fproxy.html) 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 le protocole HTTP/1.0 avec connexions non persistantes. Elles peuvent être définies via la directive [SetEnv](../mod/mod%5Fenv.html#setenv).

Il s'agit des variables force-proxy-request-1.0 etproxy-nokeepalive.

<Location "/buggyappserver/"> ProxyPass "http://buggyappserver:7001/foo/" SetEnv force-proxy-request-1.0 1 SetEnv proxy-nokeepalive 1

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[mod_proxy](../mod/mod%5Fproxy.html) dans le traitement de la requête courante. Cette variable doit être définie via la directive [SetEnvIf](../mod/mod%5Fsetenvif.html#setenvif) car la directive [SetEnv](../mod/mod%5Fenv.html#setenv) n'est pas évaluée assez tôt.

Corps de requêtes

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êteContent-Length. Lorsqu'il fait suivre ce genre de requête vers le serveur demandé, [mod_proxy_http](../mod/mod%5Fproxy%5Fhttp.html) s'efforce toujours d'envoyer l'en-tête Content-Length. 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 variables d'environnement. Ainsi, si elle est définie, la variableproxy-sendcl assure une compatibilité maximale avec les serveurs demandés en imposant l'envoi de l'en-têteContent-Length, alors queproxy-sendchunked diminue la consommation de ressources en imposant l'utilisation d'un codage à fractionnement.

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 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.

En-têtes de requête du mandataire inverse

Lorsqu'il est configuré en mode mandataire inverse (en utilisant par exemple la directive [ProxyPass](#proxypass)),[mod_proxy_http](../mod/mod%5Fproxy%5Fhttp.html) ajoute plusieurs en-têtes de requête afin de transmettre des informations au serveur demandé. Ces en-têtes sont les suivants :

X-Forwarded-For

L'adresse IP du client.

X-Forwarded-Host

L'hôte d'origine demandé par le client dans l'en-tête de requête HTTP Host.

X-Forwarded-Server

Le nom d'hôte du serveur mandataire.

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%{X-Forwarded-For}i 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.

Voir aussi les directives [ProxyPreserveHost](#proxypreservehost) et [ProxyVia](#proxyvia) directives, qui permettent de contrôler d'autres en-têtes de requête.

Note : Si vous devez ajouter des en-têtes particuliers à la requête mandatée, utilisez la directive [RequestHeader](../mod/mod%5Fheaders.html#requestheader).

Directive BalancerGrowth

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.

Directive BalancerInherit

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.

Les définitions au niveau du serveur principal constituent les définitions par défaut au niveau des serveurs virtuels.

Directive BalancerMember

Cette directive permet d'ajouter un membre à un groupe de répartition de charge. Elle peut se trouver dans un conteneur<Proxy balancer://...>, et accepte tous les paramètres de paires clé/valeur que supporte la directive[ProxyPass](#proxypass).

La directive BalancerMember accepte un paramètre supplémentaire : loadfactor. Il s'agit du facteur de charge du membre - un nombre décimal entre 1.0 (valeur par défaut) et 100.0, qui définit la charge à appliquer au membre en question.

L'argument balancerurl n'est requis que s'il ne se trouve pas dèjà dans la directive de conteneur <Proxybalancer://...>. Il correspond à l'URL d'un répartiteur de charge défini par une directive [ProxyPass](#proxypass).

La partie chemin de l'URL du répartiteur dans toute directive de conteneur <Proxy balancer://...> est ignorée.

En particulier, le slash de fin de l'URL d'unBalancerMember doit être supprimé.

Directive BalancerPersist

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.

Directive NoProxy

Cette directive n'a d'utilité que pour les serveurs mandataires Apache httpd au sein d'Intranets. La directiveNoProxy permet de spécifier une liste de sous-réseaux, d'adresses IP, de serveurs et/ou de domaines séparés par des espaces. Une requête pour un serveur qui correspond à un ou plusieurs critères sera toujours servie par ce serveur directement, sans être redirigée vers le(s) serveur(s) mandataire(s) défini(s) par la directive [ProxyRemote](#proxyremote).

Exemple

ProxyRemote "*" "http://firewall.example.com:81" NoProxy ".example.com" "192.168.112.0/21"

Le type des arguments serveur de la directiveNoProxy appartiennent à la liste suivante :

Domaine

Un domaine est ici un nom de domaine DNS partiellement qualifié précédé d'un point. Il représente une liste de serveurs qui appartiennent logiquement au même domaine ou à la même zonz DNS (en d'autres termes, les nom des serveurs se terminent tous pardomaine).

Exemple

.com .example.org.

Pour faire la distinction entre domaines et nom d'hôtes (des points de vue à la fois syntaxique et sémantique, un domaine DNS pouvant aussi avoir un enregistrement DNS de type A !), les domaines sont toujours spécifiés en les préfixant par un point.

Note

Les comparaisons de noms de domaines s'effectuent sans tenir compte de la casse, et les parties droites des Domaines sont toujours censées correspondre à la racine de l'arborescence DNS, si bien que les domaines .ExEmple.com et.exemple.com. (notez le point à la fin du nom) sont considérés comme identiques. Comme une comparaison de domaines ne nécessite pas de recherche DNS, elle est beaucoup plus efficace qu'une comparaison de sous-réseaux.

Sous-réseau

Un Sous-réseau est une adresse internet partiellement qualifiée sous forme numérique (quatre nombres séparés par des points), optionnellement suivie d'un slash et du masque de sous-réseau spécifiant le nombre de bits significatifs dans leSous-réseau. Il représente un sous-réseau de serveurs qui peuvent être atteints depuis la même interface réseau. En l'absence de masque de sous-réseau explicite, il est sous-entendu que les digits manquants (ou caractères 0) de fin spécifient le masque de sous-réseau (Dans ce cas, le masque de sous-réseau ne peut être qu'un multiple de 8). Voici quelques exemples :

192.168 ou 192.168.0.0

le sous-réseau 192.168.0.0 avec un masque de sous-réseau implicite de 16 bits significatifs (parfois exprimé sous la forme255.255.0.0)

192.168.112.0/21

le sous-réseau 192.168.112.0/21 avec un masque de sous-réseau implicite de 21 bits significatifs (parfois exprimé sous la forme255.255.248.0)

Comme cas extrêmes, un Sous-réseau avec un masque de sous-réseau de 32 bits significatifs est équivalent à une adresse IP, alors qu'un Sous-réseau avec un masque de sous-réseau de 0 bit significatif (c'est à dire 0.0.0.0/0) est identique à la constante _Default_, et peut correspondre à toute adresse IP.

Adresse IP

Une Adresse IP est une adresse internet pleinement qualifiée sous forme numérique (quatre nombres séparés par des points). En général, cette adresse représente un serveur, mais elle ne doit pas nécessairement correspondre à un nom de domaine DNS.

Note

Une Adresse IP ne nécessite pas de résolution DNS, et peut ainsi s'avérer plus efficace quant aux performances d'Apache.

Nom de serveur

Un Nom de serveur est un nom de domaine DNS pleinement qualifié qui peut être résolu en une ou plusieurs adresses IP par le service de noms de domaines DNS. Il représente un hôte logique (par opposition aux Domaines, voir ci-dessus), et doit pouvoir être résolu en une ou plusieurs adresses IP (ou souvent en une liste d'hôtes avec différentes adresses IP).

Exemples

prep.ai.example.edu www.example.org

Note

Dans de nombreuses situations, il est plus efficace de spécifier une adresse IP qu'unNom de serveur car cela évite d'avoir à effectuer une recherche DNS. La résolution de nom dans Apache httpd peut prendre un temps très long lorsque la connexion avec le serveur de noms utilise une liaison PPP lente.

Les comparaisons de Nom de serveur s'effectuent sans tenir compte de la casse, et les parties droites des Noms de serveur sont toujours censées correspondre à la racine de l'arborescence DNS, si bien que les domaines WWW.ExEmple.com etwww.example.com. (notez le point à la fin du nom) sont considérés comme identiques.

Voir aussi

• Problèmes liés au DNS

Directive

Les directives situées dans une section <Proxy> ne s'appliquent qu'au contenu mandaté concerné. Les jokers de style shell sont autorisés.

Par exemple, les lignes suivantes n'autoriseront à accéder à un contenu via votre serveur mandataire que les hôtes appartenant àvotre-reseau.example.com :

<Proxy "*"> Require host votre-reseau.example.com

Dans l'exemple suivant, tous les fichiers du répertoirefoo de example.com seront traités par le filtre INCLUDES lorsqu'ils seront envoyés par l'intermédiaire du serveur mandataire :

<Proxy "" title="undefined" rel="noopener noreferrer">http://example.com/foo/*"> SetOutputFilter INCLUDES

Différences avec la section de configuration Location

Une URL d'arrière-plan sera concernée par le conteneur Proxy si elle commence par la url-avec-jokers, 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 "" title="undefined" rel="noopener noreferrer">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 [<Location>](../mod/core.html#location) qui, pour le cas de cette note, traitera le segment de chemin final comme s'il se terminait par un slash.

Pour un contrôle plus fin de la correspondance des URL, voir la directive <ProxyMatch>.

Voir aussi

• [<ProxyMatch>](#proxymatch)

Directive Proxy100Continue

Cette directive permet de contrôler le transfert par le mandataire du message "100-continue" (_Expect:_ation) vers le serveur d'origine. Si elle est définie à "On", le serveur d'origine décidera lui-même si le corps de la requête HTTP doit être lu. Si elle est définie à "Off", le mandataire générera lui-même une réponse intermédiaire 100 Continue avant de transférer le corps de la requête.

Contexte d'utilisation

Cette option n'est utilisable qu'avec les mandataires HTTP gérés par[mod_proxy_http](../mod/mod%5Fproxy%5Fhttp.html).

Directive ProxyAddHeaders

Cette directive permet de passer au serveur d'arrière-plan des informations à propos du mandataire via les en-têtes HTTP X-Forwarded-For, X-Forwarded-Host et X-Forwarded-Server.

Utilité

Cette option n'est utile que dans le cas du mandat HTTP traité par [mod_proxy_http](../mod/mod%5Fproxy%5Fhttp.html).

Directive ProxyBadHeader

La directive ProxyBadHeader permet de déterminer le comportement de [mod_proxy](../mod/mod%5Fproxy.html) 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 :

IsError

Annule la requête et renvoie une réponse de code 502 (mauvaise passerelle). C'est le comportement par défaut.

Ignore

Traite les lignes d'en-tête incorrectes comme si elles n'avaient pas été envoyées.

StartBody

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.

Directive ProxyBlock

La directive ProxyBlock permet de spécifier une liste de termes, serveurs et/ou domaines, séparés par des espaces. Les requêtes de documents HTTP, HTTPS, FTP vers des sites dont les noms contiennent des termes, noms de serveur ou domaine correspondants seront bloqués par le serveur mandataire. La module proxy va aussi tenter de déterminer les adresses IP des éléments de la liste qui peuvent correspondre à des noms d'hôtes au cours du démarrage, et les mettra en cache à des fins de comparaisons ultérieures. Ceci peut ralentir le démarrage du serveur.

Exemple

ProxyBlock "news.example.com" "auctions.example.com" "friends.example.com"

Notez qu'example suffirait aussi pour atteindre ces sites.

Hosts conviendrait aussi s'il était référencé par adresse IP.

Notez aussi que

ProxyBlock "*"

bloque les connexions vers tous les sites.

Directive ProxyDomain

Cette directive n'a d'utilité que pour les serveurs mandataires Apache httpd au sein d'un Intranet. La directiveProxyDomain permet de spécifier le domaine par défaut auquel le serveur mandataire apache appartient. Si le serveur reçoit une requête pour un hôte sans nom de domaine, il va générer une réponse de redirection vers le même hôte suffixé par leDomaine spécifié.

Exemple

ProxyRemote "*" "http://firewall.example.com:81" NoProxy ".example.com" "192.168.112.0/21" ProxyDomain ".example.com"

Directive ProxyErrorOverride

Cette directive est utile pour les configurations de mandataires inverses, lorsque vous souhaitez que les pages d'erreur envoyées aux utilisateurs finaux présentent un aspect homogène. Elle permet aussi l'inclusion de fichiers (via les SSI de[mod_include](../mod/mod%5Finclude.html)) pour obtenir le code d'erreur et agir en conséquence (le comportement par défaut afficherait la page d'erreur du serveur mandaté, alors que c'est le message d'erreur SSI qui sera affiché si cette directive est à "on").

Cette directive n'affecte pas le traitement des réponses informatives (1xx), de type succès normal (2xx), ou de redirection (3xx).

Par défaut, ProxyErrorOverride affecte toutes les réponses avec un code compris entre 400 inclus et 600 exclus.

Exemple de configuration par défaut

ProxyErrorOverride On

Pour n'affecter que les réponses possèdant certains codes d'état particuliers, vous pouvez spécifier ces derniers sous la forme d'une liste en les séparant par des espaces. Les réponses dont le code d'état ne fait pas partie de la liste ne seront pas affectées. Vous ne pouvez spécifier que des codes d'erreurs, donc compris entre 400 inclus et 600 exclus.

Exemple de configuration personnalisée

ProxyErrorOverride On 403 405 500 501 502 503 504

Directive ProxyIOBufferSize

La directive ProxyIOBufferSize permet d'ajuster la taille du tampon interne utilisé comme bloc-note pour les transferts de données entre entrée et sortie. La taille minimale est de 512 octets.

Dans la plupart des cas, il n'y a aucune raison de modifier cette valeur.

Si elle est utilisée avec AJP, cette directive permet de définir la taille maximale du paquet AJP en octets. Si la valeur spécifiée est supérieure à 65536, elle est corrigée et prend la valeur 65536. Si vous ne conservez pas la valeur par défaut, vous devez aussi modifier l'attributpacketSize de votre connecteur AJP du côté de Tomcat ! L'attribut packetSize n'est disponible que dans Tomcat5.5.20+ et 6.0.2+.

Il n'est normalement pas nécessaire de modifier la taille maximale du paquet. Des problèmes ont cependant été rapportés avec la valeur par défaut lors de l'envoi de certificats ou de chaînes de certificats.

Directive

La directive <ProxyMatch> est identique à la directive [<Proxy>](#proxy), à l'exception qu'elle définit les URLs auxquelles elle s'applique en utilisant une expression rationnelle.

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 expressions ou au sein de modules comme [mod_rewrite](../mod/mod%5Frewrite.html). 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.

<ProxyMatch "^http://(?[^/]+)"> Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example

Voir aussi

• [<Proxy>](#proxy)

Directive ProxyMaxForwards

La directive ProxyMaxForwards permet de spécifier le nombre maximum de mandataires à travers lesquels une requête peut passer dans le cas où la la requête ne contient pas d'en-tête Max-Forwards. Ceci permet de se prémunir contre les boucles infinies de mandataires ou contre les attaques de type déni de service.

Exemple

ProxyMaxForwards 15

Notez que la définition de la directiveProxyMaxForwards constitue une violation du protocole HTTP/1.1 (RFC2616), qui interdit à un mandataire de définir Max-Forwards si le client ne l'a pas fait lui-même. Les versions précédentes d'Apache httpd la définissaient systématiquement. Une valeur négative deProxyMaxForwards, y compris la valeur par défaut -1, implique un comportement compatible avec le protocole, mais vous expose aux bouclages infinis.

Directive ProxyPass

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é mandataire inverse oupasserelle. L'argument chemin est le nom d'un chemin virtuel local ; url est une URL partielle pour le serveur distant et ne doit pas contenir de chaîne d'arguments.

Il est fortement recommandé de revoir le concept de Worker avant d'aller plus loin.

En général, la directive [ProxyRequests](#proxyrequests) doit être définie àoff lorsqu'on utilise la directiveProxyPass.

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 parunix:/path/lis.sock|. Par exemple, pour mandater HTTP et cibler l'UDS /home/www.socket, vous devez utiliserunix:/home/www.socket|http://localhost/whatever/.

**Note :**Le chemin associé à l'URLunix: tient compte de la directiveDefaultRuntimeDir.

Lorsque cette directive est utilisée dans une section [<Location>](../mod/core.html#location), le premier argument est omis et le répertoire local est obtenu à partir de l'argument de la directive [<Location>](../mod/core.html#location). Il en est de même à l'intérieur d'une section [<LocationMatch>](../mod/core.html#locationmatch), mais le résultat ne sera probablement pas celui attendu car ProxyPassReverse va interpréter l'expression rationnelle littéralement comme un chemin ; si besoin est dans ce cas, définissez la directive ProxyPassReverse en dehors de la section, ou dans une section [<Location>](../mod/core.html#location) séparée.

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

<Location "/mirror/foo/"> ProxyPass "http://backend.example.com/"

va convertir en interne toute requête pourhttp://example.com/mirror/foo/bar en une requête mandatée pour http://backend.example.com/bar.

Si vous avez besoin d'un configuration de mandataire inverse plus souple, reportez-vous à la documentaion de la directive [RewriteRule](../mod/mod%5Frewrite.html#rewriterule) et son drapeau[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 Balancer Manager :

ProxyPass "/mirror/foo/" "http://backend.example.com/"

Si le premier argument se termine par un slash**/**, 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.

Le drapeau ! permet de soustraire un sous-répertoire du mandat inverse, comme dans l'exemple suivant :

<Location "/mirror/foo/"> ProxyPass "http://backend.example.com/" <Location "/mirror/foo/i"> ProxyPass "!"

ProxyPass "/mirror/foo/i" "!" ProxyPass "/mirror/foo" "http://backend.example.com"

va mandater toutes les requêtes pour /mirror/foo vers backend.example.com, sauf les requêtes pour /mirror/foo/i.

Mélanger plusieurs configurations ProxyPass dans différents contextes ne fonctionne pas :

ProxyPass "/mirror/foo/i" "!" <Location "/mirror/foo/"> ProxyPass "http://backend.example.com/"

Dans ce cas, une requête pour /mirror/foo/i sera tout de même mandatée car c'est la directive ProxyPass de la section Location qui sera évaluée en premier. Le fait que la directiveProxyPass supporte les deux contextes serveur principal et répertoire ne signifie pas que sa portée et sa position dans le fichier de configuration va garantir une quelconque priorité et/ou chronologie de prise en compte.

Ordre de classement des directives ProxyPass

Les directives [ProxyPass](#proxypass) et [ProxyPassMatch](#proxypassmatch) 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 [ProxyPass](#proxypass) 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 relation avec le partage de workers.

Chronologie de prise en compte des directives ProxyPass au sein des sections Locations

On ne peut placer qu'une seule directive [ProxyPass](#proxypass) dans une section[Location](../mod/core.html#location), et c'est la section la plus spécifique qui l'emportera.

Exclusions et variable d'environnement no-proxy

Les exclusions doivent se situer avant les directives ProxyPass générales. A partir de la version 2.4.26 du serveur HTTP Apache, la variable d'environnement "no-proxy" est une alternative aux exclusions et constitue le seul moyen de configurer une exclusion pour une directiveProxyPass dans le contexte d'une section [Location](../mod/core.html#location). Cette variable doit être définie via la directive [SetEnvIf](../mod/mod%5Fsetenvif.html#setenvif) car la directive [SetEnv](../mod/mod%5Fenv.html#setenv) n'est pas évaluée assez tôt.

ProxyPass clé=valeur Paramètres

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 ProxyPass au moyen de paramètresclé=valeur dont la description fait l'objet des tableaux ci-dessous.

Nombre maximum de connexions vers l'arrière-plan

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 max permet de réduire cette valeur par défaut. Le jeu de connexions est maintenu au niveau de chaque processus enfant du serveur web, max et les 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é.

Le paramètre ttl, quant à lui, permet de définir une durée de vie optionnelle ; les connexions qui n'ont pas été utilisées pendant au moinsttl secondes seront fermées. ttl 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.

Exemple

ProxyPass "/example" "http://backend.example.com" max=20 ttl=120 retry=300

Si l'URL de la directive Proxy débute parbalancer:// (par exemple:balancer://cluster, toute information relative au chemin est ignorée), alors un serveur cible virtuel ne communiquant pas réellement avec le serveur d'arrière-plan sera créé. Celui-ci sera en fait responsable de la gestion de plusieurs serveurs cibles "réels". Dans ce cas, un jeu de paramètres particuliers s'applique à ce serveur cible virtuel. Voir [mod_proxy_balancer](../mod/mod%5Fproxy%5Fbalancer.html) pour plus d'informations à propos du fonctionnement du répartiteur de charge.

Exemple de configuration d'un répartiteur de charge

ProxyPass "/special-area" "http://special.example.com" smax=5 max=10 ProxyPass "/" "balancer://mycluster/" stickysession=JSESSIONID|jsessionid nofailover=On <Proxy "balancer://mycluster"> BalancerMember "ajp://1.2.3.4:8009" BalancerMember "ajp://1.2.3.5:8009" loadfactor=20 # Less powerful server, don't send as many requests there, BalancerMember "ajp://1.2.3.6:8009" loadfactor=5

La définition de remplaçants à chaud permet de s'assurer qu'un nombre déterminé de serveurs sera toujours disponible dans le jeu de serveurs cibles :

ProxyPass "/" "balancer://sparecluster/" <Proxy balancer://sparecluster> BalancerMember ajp://1.2.3.4:8009 BalancerMember ajp://1.2.3.5:8009 # Les serveurs ci-dessous sont des remplaçants à chaud. Pour chaque serveur # ci-dessus qui viendrait à être inutilisable (maintenance, arrêt, non # contactable, en erreur, etc...), un de ces remplaçants à chaud prendra sa # place. Deux serveurs seront toujours disponibles pour traiter une requête # (à moins qu'un ou plusieurs remplaçant à chaud soit lui aussi # indisponible). BalancerMember ajp://1.2.3.6:8009 status=+R BalancerMember ajp://1.2.3.7:8009 status=+R

Configuration d'un serveur cible de réserve qui ne sera utilisé que si aucun autre serveur cible ou remplaçant à chaud n'est disponible dans le jeu de serveurs cibles :

ProxyPass "/" "balancer://hotcluster/" <Proxy "balancer://hotcluster"> BalancerMember "ajp://1.2.3.4:8009" loadfactor=1 BalancerMember "ajp://1.2.3.5:8009" loadfactor=2.25 # The server below is on hot standby BalancerMember "ajp://1.2.3.6:8009" status=+H ProxySet lbmethod=bytraffic

Mots-clés additionnels de ProxyPass

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

Par défaut, mod_proxy inclut la chaîne de paramètres lors de la génération de la variable d'environnementSCRIPT_FILENAME. Le mot-clé optionnel noquery (disponible à partir de la version 2.4.1) permet d'exclure cette chaîne.

Lorsque la directive ProxyPass est utilisée à l'intérieur d'une section [<Location>](../mod/core.html#location), le premier argument est omis et le répertoire local est obtenu à partir de la section [<Location>](../mod/core.html#location). Il en sera de même dans une section [<LocationMatch>](../mod/core.html#locationmatch) ; cependant, ProxyPass n'interprète pas les expressions rationnelles, et il sera ici nécessaire d'utiliser la directiveProxyPassMatch à la place.

Cette directive ne peut pas être placée dans une section[<Directory>](../mod/core.html#directory) ou[<Files>](../mod/core.html#files).

Si vous avez besoin d'un configuration de mandataire inverse plus souple, reportez-vous à la documentaion de la directive [RewriteRule](../mod/mod%5Frewrite.html#rewriterule) et son drapeau[P].

Le mot-clé optionnel interpolate, en combinaison avec la directive[ProxyPassInterpolateEnv](#proxypassinterpolateenv), permet à ProxyPass d'interpoler les variables d'environnement à l'aide de la syntaxe${VARNAME}. Notez que de nombreuses variables d'environnement standard dérivées de CGI n'existeront pas lorsque l'interpolation se produit ; vous devrez alors encore avoir avoir recours à [mod_rewrite](../mod/mod%5Frewrite.html) pour des règles complexes. Notez aussi que l'interpolation n'est supportée dans la partie protocole/hostname/port d'une URL que pour les variables qui sont disponibles au moment où la directive est interprétée (comme pour la directive [Define](../mod/core.html#define)). La détermination dynamique de ces champs peut être effectuée à l'aide de[mod_rewrite](../mod/mod%5Frewrite.html), et l'exemple suivant décrit comment utiliser[mod_rewrite](../mod/mod%5Frewrite.html) pour définir dynamiquement le protocole à http ou https :

RewriteEngine On

RewriteCond "%{HTTPS}" =off RewriteRule "". "-" [E=protocol:http] RewriteCond "%{HTTPS}" =on RewriteRule "." "-" [E=protocol:https]

RewriteRule "^/mirror/foo/(.*)" "%{ENV:protocol}://backend.example.com/$1" [P] ProxyPassReverse "/mirror/foo/" "http://backend.example.com/" ProxyPassReverse "/mirror/foo/" "https://backend.example.com/"

Promotion de protocole

Depuis la version 2.4.47 du serveur HTTP Apache, la promotion de protocole (tunneling) peut être géré bout à bout par[mod_proxy_http](../mod/mod%5Fproxy%5Fhttp.html) en utilisant le paramètre upgrade.

Bout à bout signifie que la requête de promotion de protocole en provenance du client/navigateur est tout d'abord transmise par[mod_proxy_http](../mod/mod%5Fproxy%5Fhttp.html) au serveur origine et que le protocole de la connexion ne sera modifié (et « tunnelisé » par[mod_proxy_http](../mod/mod%5Fproxy%5Fhttp.html)) que si le serveur origine accepte/initie la promotion (réponse HTTP 101 Switching Protocols). Si le serveur origine renvoie une réponse différente,[mod_proxy_http](../mod/mod%5Fproxy%5Fhttp.html) continuera la transmission en utilisant (et en forçant) le protocole HTTP habituel pour cette connexion.

Voir Promotion de protocole vers Websocket (versions 2.4.47 et ultérieures) pour un exemple de configuration qui utilise[mod_proxy_http](../mod/mod%5Fproxy%5Fhttp.html).

Avec les versions 2.4.46 et antérieures du serveur HTTP Apache (ou si la directive [ProxyWebsocketFallbackToProxyHttp](../mod/mod%5Fproxy%5Fwstunnel.html#proxywebsocketfallbacktoproxyhttp) des versions 2.4.48 et ultérieures désactive la prise en charge par[mod_proxy_http](../mod/mod%5Fproxy%5Fhttp.html)), voir la documentation de[mod_proxy_wstunnel](../mod/mod%5Fproxy%5Fwstunnel.html) pour la méthode permettant de mandater le protocole WebSocket.

Directive ProxyPassInherit

Cette directive permet à un serveur virtuel d'hériter des directives [ProxyPass](#proxypass) 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.

Les valeurs définies au niveau du serveur principal constituent les valeurs par défaut pour tous les serveurs virtuels.

La désactivation de ProxyPassInherit désactive aussi la directive [BalancerInherit](#balancerinherit).

Directive ProxyPassInterpolateEnv

Cette directive, ainsi que l'argument interpolate des directives ProxyPass,ProxyPassReverse,ProxyPassReverseCookieDomain etProxyPassReverseCookiePath, permet de configurer dynamiquement un mandataire inverse à l'aide de variables d'environnement, ces dernières pouvant être définies par un autre module comme [mod_rewrite](../mod/mod%5Frewrite.html). Elle affecte les directives ProxyPass,ProxyPassReverse,ProxyPassReverseCookieDomain, etProxyPassReverseCookiePath, en leur indiquant de remplacer la chaîne ${nom_var} dans les directives de configuration par la valeur de la variable d'environnementnom_var (si l'option interpolate est spécifiée).

La partie protocole/hostname/port de ProxyPass peut contenir des variables, mais seulement celles qui sont accessibles au moment où la directive est interprétée (similairement à la directive[Define](../mod/core.html#define)). Pour tous les autres cas, utilisez plutôt [mod_rewrite](../mod/mod%5Frewrite.html).

Avertissement concernant les performances

Laissez cette directive à off, à moins que vous n'en ayez réellemnt besoin ! Par exemple, ajouter des variables àProxyPass peut entraîner l'utilisation des serveurs d'arrière-plan de mod_proxy configurés par défaut, et ceux-ci ne permettent pas un réglage fin comme la réutilisation des connexions, entre autres...).

Directive ProxyPassMatch

Cette directive est identique à la directive [ProxyPass](#proxypass), mais fait usage des expressions rationnelles, au lieu d'une simple comparaison de préfixes. L'expression rationnelle spécifiée est comparée à l'url, et si elle correspond, le serveur va substituer toute correspondance entre parenthèses dans la chaîne donnée et l'utiliser comme nouvelle url.

Note : Cette directive ne peut pas être utilisée dans un contexte de niveau répertoire.

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

ProxyPassMatch "^(/.*.gif)$" "http://backend.example.com/$1"

va provoquer la conversion interne de la requête localehttp://example.com/foo/bar.gif en une requête mandatée pour http://backend.example.com/foo/bar.gif.

Le drapeau ! vous permet de ne pas mandater un sous-répertoire donné.

Dans une section [<LocationMatch>](../mod/core.html#locationmatch), le premier argument est omis et l'expression rationnelle est obtenue à partir de la directive[<LocationMatch>](../mod/core.html#locationmatch).

Si vous avez besoin d'une configuration du mandataire inverse plus flexible, voyez la directive [RewriteRule](../mod/mod%5Frewrite.html#rewriterule) avec le drapeau[P].

Substitution par défaut

Lorsque le paramètre URL n'utilise pas de références arrières dans l'expression rationnelle, l'URL originale sera ajoutée au paramètre URL.

Paramètres key=value et url avec références arrières

Depuis la version 2.4.47, les paramètres key=value ne sont plus ignorés dans une directive ProxyPassMatch lorsqu'on utilise une url contenant des références arrières. Cependant, pour conserver le comportement précédent relatif à la réutilisation/conservation des connexions d'arrière-plan (qui n'avaient jamais été réutilisées auparavant pour ces URLs), les paramètresenablereuse et disablereuse prendront dans ce cas respectivement comme valeurs par défaut off eton. Définir explicitement enablereuse=on permet de réutiliser les connexions, sauf si des références arrières se trouvent dans la partie authority (nom d'hôte et/ou port) de l'url (cette condition est imposée depuis la version 2.4.55 du serveur HTTP Apache et provoque un avertissement au démarrage car ces URLs ne sont pas réutilisables sous cette forme).

Avertissement à propos de la sécurité

Lors de la construction de l'URL cible de la règle, il convient de prendre en compte l'impact en matière de sécurité qu'aura le fait de permettre au client d'influencer le jeu d'URLs pour lesquelles votre serveur agira en tant que mandataire. Assurez-vous que la partie protocole://nom-serveur de l'URL soit fixe, ou ne permette pas au client de l'influencer induement.

Directive ProxyPassReverse

Cette directive permet de faire en sorte qu'Apache httpd ajuste l'URL dans les en-têtes Location,Content-Location et URI des réponses de redirection HTTP. Ceci est essentiel lorsqu'Apache httpd est utilisé en tant que mandataire inverse (ou passerelle), afin d'éviter de court-circuiter le mandataire inverse suite aux redirections HTTP sur le serveur d'arrière-plan qui restent derrière le mandataire inverse.

Seuls les en-têtes de réponse HTTP spécialement mentionnés ci-dessus seront réécrits. Apache httpd ne réécrira ni les autres en-têtes de réponse, ni par défaut les références d'URLs dans les pages HTML. Cela signifie que dans le cas où un contenu mandaté contient des références à des URLs absolues, elles court-circuiteront le mandataire. Pour réécrire un contenu HTML afin qu'il corresponde au mandataire, vous devez charger et activer le module[mod_proxy_html](../mod/mod%5Fproxy%5Fhtml.html).

chemin est le nom d'un chemin virtuel local.url est une URL partielle pour le serveur distant. Ces paramètres s'utilisent de la même façon qu'avec la directive [ProxyPass](#proxypass).

Supposons par exemple que le serveur local a pour adressehttp://example.com/ ; alors

ProxyPass "/mirror/foo/" "http://backend.example.com/" ProxyPassReverse "/mirror/foo/" "http://backend.example.com/" ProxyPassReverseCookieDomain "backend.example.com" "public.example.com" ProxyPassReverseCookiePath "/" "/mirror/foo/"

ne va pas seulement provoquer la conversion interne d'une requête locale pour http://example.com/mirror/foo/bar en une requête mandatée pour http://backend.example.com/bar (la fonctionnalité fournie par ProxyPass). Il va aussi s'occuper des redirections que le serveurbackend.example.com envoie lorsqu'il redirigehttp://backend.example.com/bar vershttp://backend.example.com/quux. Apache httpd corrige ceci en http://example.com/mirror/foo/quux avant de faire suivre la redirection HTTP au client. Notez que le nom d'hôte utilisé pour construire l'URL est choisi en respectant la définition de la directive [UseCanonicalName](../mod/core.html#usecanonicalname).

Notez que la directive ProxyPassReverse peut aussi être utilisée en conjonction avec la fonctionnalité de mandataire (RewriteRule ... [P]) du module[mod_rewrite](../mod/mod%5Frewrite.html), car elle ne dépend pas d'une directive[ProxyPass](#proxypass) correspondante.

Le mot-clé optionnel interpolate, en combinaison avec la directive [ProxyPassInterpolateEnv](#proxypassinterpolateenv), permet l'interpolation des variables d'environnement spécifiées en utilisant le format ${VARNAME} Notez que l'interpolation n'est pas supportée dans la partie protocole d'une URL.

Lorsque cette directive est utilisée dans une section [<Location>](../mod/core.html#location), le premier argument est omis et le répertoire local est obtenu à partir de l'argument de la directive [<Location>](../mod/core.html#location). Il en est de même à l'intérieur d'une section [<LocationMatch>](../mod/core.html#locationmatch), mais le résultat ne sera probablement pas celui attendu car ProxyPassReverse va interpréter l'expression rationnelle littéralement comme un chemin ; si besoin est dans ce cas, définissez la directive ProxyPassReverse en dehors de la section, ou dans une section [<Location>](../mod/core.html#location) séparée.

Cette directive ne peut pas être placée dans une section[<Directory>](../mod/core.html#directory) ou[<Files>](../mod/core.html#files).

Directive ProxyPassReverseCookieDomain

L'utilisation de cette directive est similaire à celle de la directive [ProxyPassReverse](#proxypassreverse), mais au lieu de réécrire des en-têtes qui contiennent des URLs, elle réécrit la chaîne correspondant au domaine dans les en-têtesSet-Cookie.

Directive ProxyPassReverseCookiePath

Cette directive s'avère utile en conjonction avec la directive[ProxyPassReverse](#proxypassreverse) dans les situations où les chemins d'URL d'arrière-plan correspondent à des chemins publics sur le mandataire inverse. Cette directive permet de réécrire la chaîne path dans les en-têtesSet-Cookie. Si le début du chemin du cookie correspond àchemin-interne, le chemin du cookie sera remplacé parchemin-public.

Dans l'exemple fourni avec la directive [ProxyPassReverse](#proxypassreverse), la directive :

ProxyPassReverseCookiePath "/" "/mirror/foo/"

va réécrire un cookie possédant un chemin d'arrière-plan /(ou /example ou en fait tout chemin) en /mirror/foo/..

Directive ProxyPreserveHost

Lorsqu'elle est activée, cette directive va transmettre l'en-têteHost: de la requête entrante vers le serveur mandaté, au lieu du nom d'hôte spécifié par la directive [ProxyPass](#proxypass).

Cette directive est habituellement définie à Off. 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.

Directive ProxyReceiveBufferSize

La directive ProxyReceiveBufferSize permet de spécifier une taille de tampon réseau explicite (TCP/IP) pour les connexions mandatées HTTP et FTP, afin d'améliorer le débit de données. Elle doit être supérieure à 512 ou définie à0 pour indiquer que la taille de tampon par défaut du système doit être utilisée.

Exemple

ProxyReceiveBufferSize 2048

Directive ProxyRemote

Cette directive permet de définir des mandataires distants pour ce mandataire. match 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 * pour indiquer que le serveur distant doit être utilisé pour toutes les requêtes. remote-server est une URL partielle correspondant au serveur distant. Syntaxe :

remote-server =scheme://hostname[:port]

scheme est effectivement le protocole à utiliser pour communiquer avec le serveur distant ; ce module ne supporte quehttp et https. Lorsqu'on utilisehttps, les requêtes sont redirigées par le mandataire distant en utilisant la méthode HTTP CONNECT.

Exemple

ProxyRemote "http://goodguys.example.com/" "http://mirrorguys.example.com:8000" ProxyRemote "*" "http://cleverproxy.localdomain" ProxyRemote "ftp" "http://ftpproxy.mydomain:8080"

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.

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é par un autre mandataire direct.

Le troisième argument optionnel username:password permet de spécifier des données d'authentification basiques à transmettre au mandataire distant défini. Ces données d'authentification seront toujoujours envoyées sans attendre que le mandataire distant n'effectue une demande d'authentification. La variable d'environnement Proxy-Chain-Auth n'est plus prise en compte si cet argument est utilisé.

Directive ProxyRemoteMatch

La directive ProxyRemoteMatch est identique à la directive [ProxyRemote](#proxyremote), à l'exception du premier argument qui est une expression rationnelle à mettre en correspondance avec l'URL de la requête.

Directive ProxyRequests

Cette directive permet d'activer/désactiver la fonctionnalité de serveur mandataire direct d'Apache httpd. Définir ProxyRequests àOff n'interdit pas l'utilisation de la directive[ProxyPass](#proxypass).

Pour une configuration typique de mandataire inverse ou passerelle, cette directive doit être définie àOff.

Afin d'activer la fonctionnalité de mandataire pour des sites HTTP et/ou FTP, les modules [mod_proxy_http](../mod/mod%5Fproxy%5Fhttp.html) et/ou[mod_proxy_ftp](../mod/mod%5Fproxy%5Fftp.html) doivent également être chargés dans le serveur.

Pour activer la fonctionnalité de mandataire sur les sites chiffrés en HTTPS, le module[mod_proxy_connect](../mod/mod%5Fproxy%5Fconnect.html) doit également être chargé dans le serveur.

Avertissement

N'activez pas la fonctionnalité de mandataire avec la directive[ProxyRequests](#proxyrequests) avant d'avoir sécurisé votre serveur. Les serveurs mandataires ouverts sont dangereux non seulement pour votre réseau, mais aussi pour l'Internet au sens large.

Voir aussi

• Mandataires/Passerelles directs et inverses

Directive ProxySet

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 [ProxyPass](#proxypass). Si elle se trouve dans un conteneur <Proxy url de répartiteur|url de serveur cible>, l'argument url 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 mandataire inverse via une directive [RewriteRule](../mod/mod%5Frewrite.html#rewriterule) au lieu de [ProxyPass](#proxypass).

<Proxy "balancer://hotcluster"> BalancerMember "http://www2.example.com:8080" loadfactor=1 BalancerMember "http://www3.example.com:8080" loadfactor=2 ProxySet lbmethod=bytraffic

<Proxy "" title="undefined" rel="noopener noreferrer">http://backend"> ProxySet keepalive=On

ProxySet "balancer://foo" lbmethod=bytraffic timeout=15

ProxySet "ajp://backend:7001" timeout=15

Avertissement

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.

Directive ProxyStatus

Cette directive permet de spécifier si les données d'état du répartiteur de charge du mandataire doivent être affichées via la page d'état du serveur du module [mod_status](../mod/mod%5Fstatus.html).

Note

L'argument Full produit le même effet que l'argument On.

Directive ProxyTimeout

Cette directive permet à l'utilisateur de spécifier un délai pour les requêtes mandatées. Ceci s'avère utile dans le cas d'un serveur d'applications lent et bogué qui a tendance à se bloquer, et si vous préférez simplement renvoyer une erreur timeout et abandonner la connexion en douceur plutôt que d'attendre jusqu'à ce que le serveur veuille bien répondre.

Directive ProxyVia

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

• Si elle est définie à Off, valeur par défaut, cette directive n'effectue aucun traitement particulier. Si une requête ou une réponse contient un en-tête Via:, il est transmis sans modification.
• Si elle est définie à On, chaque requête ou réponse se verra ajouter une ligne d'en-tête Via: pour le serveur courant.
• Si elle est définie à Full, chaque ligne d'en-têteVia: se verra ajouter la version du serveur Apache httpd sous la forme d'un champ de commentaire Via:.
• Si elle est définie à Block, chaque requête mandatée verra ses lignes d'en-tête Via: supprimées. Aucun nouvel en-tête Via: ne sera généré.