Serveur Apache HTTP Version 2.2

Apache > Serveur HTTP > Documentation > Version 2.2 > Modules

# Module Apache mod_proxy

Langues Disponibles: en | fr | ja

Description: | Serveur mandataire/passerelle HTTP/1.1
Statut: | Extension
Identificateur de Module: | proxy_module
Fichier Source: | mod_proxy.c

### Sommaire

### Avertissement

N'activez pas la fonctionnalité de mandataire avec la directive `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.

Ce module implémente un mandataire/passerelle pour Apache. Il implémente la fonctionnalité de mandataire pour `AJP13` (Apache JServe Protocol version 1.3), `FTP`, `CONNECT` (pour SSL), `HTTP/0.9`, `HTTP/1.0`, et `HTTP/1.1`. Le module peut être configuré pour se connecter aux autres modules mandataires qui gèrent ces protocoles.

Les diverses fonctionnalités de mandataire d'Apache sont réparties entre plusieurs modules complémentaires de `mod_proxy` : `mod_proxy_http`, `mod_proxy_ftp`, `mod_proxy_ajp`, `mod_proxy_balancer`, et `mod_proxy_connect`. Ainsi, si vous voulez utiliser une ou plusieurs fonctionnalités de mandataire particulières, chargez `mod_proxy` et le(s) module(s) approprié(s) dans le serveur (soit statiquement à la compilation, soit dynamiquement via la directive `LoadModule`).

En outre, d'autres modules fournissent des fonctionnalités étendues. `mod_cache` et ses modules associés fournissent la mise en cache. Les directives `SSLProxy*` du module `mod_ssl` 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.

### Directives

### Sujets

- Mandataires directs et mandataires/passerelles inverses
- Exemples simples
- Gestionnaires de serveurs (workers)
- Contrôler l'accès à votre mandataire
- Ralentissement au démarragep
- Mandataire d'Intranet
- Ajustements relatifs au protocole
- Corps de requêtes
- En-têtes de requête du mandataire inverse

### Voir aussi

- `mod_cache`
- `mod_proxy_http`
- `mod_proxy_ftp`
- `mod_proxy_connect`
- `mod_proxy_balancer`
- `mod_ssl`

- Commentaires

## Mandataires directs et mandataires/passerelles inverses

Apache peut être configuré dans les deux modes mandataire direct 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, puis le mandataire extrait 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`) pour réduire la charge du réseau.

La fonctionnalité de mandataire direct est activée via la directive `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 des utilisateurs à Internet pour 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` ou le drapeau `[P]` de la directive `RewriteRule`. Il n'est pas nécessaire de définir `ProxyRequests` à on 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`.

### Mandataire inverse

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

### Mandataire direct

`ProxyRequests On
ProxyVia On
<Proxy *>
Order deny,allow
Deny from all
Allow from interne.example.com
</Proxy>`

## Gestionnaires de serveurs (workers)

Le mandataire gère la configuration des serveurs originaux, ainsi que leurs paramètres de communication dans des objets appelés workers ou Gestionnaires de serveur. Deux workers intégrés par défaut sont disponibles : le worker de mandataire direct et le worker de mandataire inverse. Des workers supplémentaires peuvent être configurés explicitement.

Les deux workers par défaut ont une configuration fixe et seront utilisés si aucun autre worker ne correspond à la requête. Ils n'utilisent ni les connexions HTTP persistantes, ni les jeux de connexions. Les connexions TCP vers le serveur original seront donc ouvertes et fermées pour chaque requête.

Les workers configurés explicitement sont identifiés par leur URL. Dans le cas d'un mandataire inverse, ils sont généralement créés et configurés via les directives `ProxyPass` ou `ProxyPassMatch` :

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

Cet exemple crée un worker associé à l'URL du serveur original `http://backend.example.com`, et utilisant les délais spécifiés. Dans le cas d'un mandataire direct, les workers sont généralement définis via la directive `ProxySet` directive :

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

ou encore via une combinaison des directives `Proxy` et `ProxySet` :

`<Proxy http://backend.example.com>
ProxySet connectiontimeout=5 timeout=30 </Proxy>`

L'utilisation de workers configurés explicitement dans le mode direct n'est pas très courante, car les mandataires directs communiquent avec de nombreux serveurs originaux. Il est cependant intéressant de créer des workers explicites pour certains serveurs originaux si ces derniers sont utilisés très souvent. Les workers configurés explicitement n'ont en eux-mêmes aucun concept de mandataire direct ou inverse. Ils encapsulent un concept de communication commun avec les serveurs originaux. Un worker créé via la directive `ProxyPass` pour être utilisé avec un mandataire inverse, sera aussi utilisé pour les requêtes mandatées en direct chaque fois que l'URL du serveur original correspondra à l'URL du worker, et vice versa.

L'URL identifiant un worker direct correspond à l'URL de son serveur original comportant tout élément de chemin éventuel :

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

Cet exemple définit deux workers différents, chacun d'entre eux utilisant une configuration et un jeu de connexions séparés.

### Partage de worker

Le partage de worker se produit lorsque les URLs des workers se chevauchent, c'est à dire lorsque l'URL d'un worker correspond à une partie du 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 utilisé à sa place. L'avantage de ceci réside dans le fait qu'il n'y a plus qu'un jeu de connexions, celles-ci étant donc réutilisées plus souvent. Notez que tous les attributs de configuration définis explicitement pour le second worker et certaines valeurs par défaut vont écraser la configuration définie pour le premier worker, ce qui va provoquer la journalisation d'un avertissement. Dans l'exemple précédent, la valeur de délai finale pour l'URL `/apps` sera `10` au lieu de `60` !

Pour éviter ce partage, classez vos définitions de workers de l'URL la plus longue à la plus courte. Si au contraire, vous voulez favoriser ce partage, utilisez l'ordre de classement inverse. Voir aussi l'avertissement en rapport à propos de l'ordre de classement des directives `ProxyPass`.

Les workers configurés explicitement sont de deux sortes : workers directs et workers à répartition (de charge). Ils supportent de nombreux attributs de configuration importants décrits ci-dessous dans la directive `ProxyPass`. Tous ces attributs peuvent aussi être définis via la directive `ProxySet`.

Le jeu d'options disponibles pour un worker direct dépend du protocole, qui est spécifié dans l'URL du serveur original. Parmi les protocoles disponibles, on trouve `ajp`, `ftp`, `http` et `scgi`.

Les workers à répartition sont des workers virtuels qui utilisent des workers directs considérés comme leurs membres pour le traitement effectif des requêtes. Chaque répartiteur peut posséder plusieurs membres. Pour traiter une requête, il choisit un de ses membres en fonction de l'algorithme de répartition de charge défini.

Un worker à répartition est créé si son URL utilise `balancer` comme protocole. L'URL de répartition identifie de manière unique le worker à répartition. On peut ajouter des membres à un répartiteur via la directive `BalancerMember`.

## Contrôler l'accès à votre mandataire

Vous pouvez restreindre l'accès à votre mandataire via le bloc de contrôle `<Proxy>` comme dans l'exemple suivant :

`<Proxy *>
Order Deny,Allow
Deny from all
Allow from 192.168.0
</Proxy>`

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

Restreindre l'accès de manière stricte est essentiel si vous mettez en oeuvre un mandataire direct (en définissant la directive `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` 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.

## Ralentissement au démarragep

Si vous utilisez la directive `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 d'Intranet

Un serveur mandataire Apache 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` 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` 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 de `http://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` est utilisée et si le serveur est configuré comme mandataire, Apache 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` 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`.

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

`<Location /serveur-non-conforme/>
ProxyPass http://serveur-non-conforme:7001/foo/
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
</Location>`

## 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, soit envoyer un en-tête de requête `Content-Length`. Lorsqu'il fait suivre ce genre de requête vers le serveur demandé, `mod_proxy_http` 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 variable `proxy-sendcl` assure une compatibilité maximale avec les serveurs demandés en imposant l'envoi de l'en-tête `Content-Length`, alors que `proxy-sendchunked` diminue la consommation de ressources en imposant l'utilisation d'un codage à fractionnement.

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

Lorsqu'il est configuré en mode mandataire inverse (en utilisant par exemple la directive `ProxyPass`), `mod_proxy_http` 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 original 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` et `ProxyVia` directives, qui permettent de contrôler d'autres en-têtes de requête.

## AllowCONNECT Directive

Description: | Ports autorisés à se `CONNECT`er à travers le mandataire
Syntaxe: | `AllowCONNECT port [port] ...`
Défaut: | `AllowCONNECT 443 563`
Contexte: | configuration du serveur, serveur virtuel
Statut: | Extension
Module: | mod_proxy

La directive `AllowCONNECT` permet de spécifier une liste de numéros de ports auxquels la méthode de mandataire `CONNECT` pourra se connecter. Les navigateurs d'aujourd'hui utilisent cette méthode dans le cas où une connexion `https` est requise et où le tunneling mandataire sur HTTP est en service.

Par défaut, seuls les ports par défauts https (`443`) et snews (`563`) sont pris en compte. Vous pouvez utiliser la directive `AllowCONNECT` pour outrepasser ces valeurs par défaut et n'autoriser les connexions que vers les ports spécifiés.

Notez que le module `mod_proxy_connect` doit être chargé dans le serveur pour pouvoir accéder au support de `CONNECT`.

## BalancerMember Directive

Description: | Ajoute un membre à un groupe de répartition de charge
Syntaxe: | `BalancerMember [balancerurl] url [clé=valeur [clé=valeur ...]]`
Contexte: | répertoire
Statut: | Extension
Module: | mod_proxy
Compatibilité: | Disponible depuis la version 2.2 d'Apache.

Cette directive parmet 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`.

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

## NoProxy Directive

Description: | Serveurs, domaines ou réseaux auquels on se connectera directement
Syntaxe: | `NoProxy domaine [domaine] ...`
Contexte: | configuration du serveur, serveur virtuel
Statut: | Extension
Module: | mod_proxy

Cette directive n'a d'utilité que pour les serveurs mandataires Apache au sein d'Intranets. La directive `NoProxy` 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`.

### Exemple

`ProxyRemote * http://pare-feu.example.com:81
NoProxy .example.com 192.168.112.0/21`

Le type des arguments serveur de la directive `NoProxy` 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 par domaine).

  ### Exemple

  `.com .apache.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 `.example.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 le Sous-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 forme `255.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 forme`255.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.

  ### Exemple

  `192.168.123.7`

  ### 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.com
  www.apache.org`

  ### Note

  Dans de nombreuses situations, il est plus efficace de spécifier une adresse IP qu'un Nom de serveur car cela évite d'avoir à effectuer une recherche DNS. La résolution de nom dans Apache 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` et `www.example.com.` (notez le point à la fin du nom) sont considérés comme identiques.

### Voir aussi

- Problèmes liés au DNS

## <Proxy> Directive

Description: | Conteneur de directives s'appliquant à des ressources mandatées
Syntaxe: | `<Proxy url-avec-jokers> ...</Proxy>`
Contexte: | configuration du serveur, serveur virtuel
Statut: | Extension
Module: | mod_proxy

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 eexemple, les lignes suivantes n'autoriseront à accéder à un contenu via votre serveur mandataire que les hôtes appartenant à `votre-reseau.example.com` :

`<Proxy *>
Order Deny,Allow
Deny from all
Allow from votre-reseau.example.com
</Proxy>`

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

`<Proxy http://example.com/foo/*>
SetOutputFilter INCLUDES
</Proxy>`

### Voir aussi

- `<ProxyMatch>`

## ProxyBadHeader Directive

Description: | Détermine la manière de traiter les lignes d'en-tête incorrectes d'une réponse
Syntaxe: | `ProxyBadHeader IsError|Ignore|StartBody`
Défaut: | `ProxyBadHeader IsError`
Contexte: | configuration du serveur, serveur virtuel
Statut: | Extension
Module: | mod_proxy
Compatibilité: | Disponible depuis la version 2.0.44 d'Apache

La directive `ProxyBadHeader` permet de déterminer le comportement de `mod_proxy` 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.

## ProxyBlock Directive

Description: | Termes, serveurs ou domaines bloqués par le mandataire
Syntaxe: | `ProxyBlock *|terme|serveur|domaine [terme|serveur|domaine] ...`
Contexte: | configuration du serveur, serveur virtuel
Statut: | Extension
Module: | mod_proxy

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 items 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 joes-garage.com some-host.co.uk rocky.wotsamattau.edu`

`rocky.wotsamattau.edu` aurait aussi correspondu s'il avait été spécifié par son adresse IP.

Notez que `wotsamattau` aurait suffi pour correspondre à `wotsamattau.edu`.

Notez aussi que

`ProxyBlock *`

bloque les connexions vers tous les sites.

## ProxyDomain Directive

Description: | Nom de domaine par défaut pour les requêtes mandatées
Syntaxe: | `ProxyDomain Domaine`
Contexte: | configuration du serveur, serveur virtuel
Statut: | Extension
Module: | mod_proxy

Cette directive n'a d'utilité que pour les serveurs mandataires Apache au sein d'un Intranet. La directive `ProxyDomain` 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 le Domaine spécifié.

### Exemple

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

## ProxyErrorOverride Directive

Description: | Outrepasser les pages d'erreur pour les contenus mandatés
Syntaxe: | `ProxyErrorOverride On|Off`
Défaut: | `ProxyErrorOverride Off`
Contexte: | configuration du serveur, serveur virtuel
Statut: | Extension
Module: | mod_proxy
Compatibilité: | Disponible depuis la version 2.0 d'Apache

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

## ProxyFtpDirCharset Directive

Description: | Définit le jeu de caractères des listings FTP mandatés
Syntaxe: | `ProxyFtpDirCharset jeu-caractères`
Défaut: | `ProxyFtpDirCharset ISO-8859-1`
Contexte: | configuration du serveur, serveur virtuel, répertoire
Statut: | Extension
Module: | mod_proxy
Compatibilité: | Disponible depuis la version 2.2.7 d'Apache

La directive `ProxyFtpDirCharset` permet de définir le jeu de caractères à utiliser pour les listings FTP en HTML générés par `mod_proxy_ftp`.

## ProxyIOBufferSize Directive

Description: | Détermine la taille du tampon interne de transfert de données
Syntaxe: | `ProxyIOBufferSize octets`
Défaut: | `ProxyIOBufferSize 8192`
Contexte: | configuration du serveur, serveur virtuel
Statut: | Extension
Module: | mod_proxy

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 doit être au minimum égale à `8192` octets.

Lorsqu'on utilise `mod_proxy_ajp`, la valeur minimale est alignée sur la limite de 1024 octets, et les valeurs supérieures à 65536 octets sont ramenées à 65536 octets, comme préconisé par le protocole AJP.

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

## <ProxyMatch> Directive

Description: | Conteneur de directives s'appliquant à des ressources mandatées correspondant à une expression rationnelle
Syntaxe: | `<ProxyMatch regex> ...</ProxyMatch>`
Contexte: | configuration du serveur, serveur virtuel
Statut: | Extension
Module: | mod_proxy

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

### Voir aussi

- `<Proxy>`

## ProxyMaxForwards Directive

Description: | Nombre maximum de mandataires à travers lesquelles une requête peut être redirigée
Syntaxe: | `ProxyMaxForwards nombre`
Défaut: | `ProxyMaxForwards -1`
Contexte: | configuration du serveur, serveur virtuel
Statut: | Extension
Module: | mod_proxy
Compatibilité: | Disponible depuis Apache 2.0 ; comportement par défaut modifié dans 2.2.7

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 directive `ProxyMaxForwards` 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 la définissaient systématiquement. Une valeur négative de `ProxyMaxForwards`, y compris la valeur par défaut -1, implique un comportement compatible avec le protocole, mais vous expose aux bouclages infinis.

## ProxyPass Directive

Description: | Référencer des serveurs distants depuis l'espace d'URLs du serveur local
Syntaxe: | `ProxyPass [chemin] !|url [clé=valeur [clé=valeur ...]] [nocanon] [interpolate]`
Contexte: | configuration du serveur, serveur virtuel, répertoire
Statut: | Extension
Module: | mod_proxy

Cette directive permet 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 ou passerelle. 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.

En général, la directive `ProxyRequests` doit être définie à off lorsqu'on utilise la directive `ProxyPass`.

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

`ProxyPass /miroir/foo/ http://backend.example.com/`

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

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 :

`ProxyPass /miroir/foo/i !
ProxyPass /miroir/foo http://backend.example.com`

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

### Ordre de classement des directives ProxyPass

Les directives `ProxyPass` et `ProxyPassMatch` sont traitées selon leur ordre d'apparition dans le fichier de configuration. La première qui correspond s'applique. Ainsi, vous devez classer les directives `ProxyPass` qui peuvent entrer en conflit, de l'URL la plus longue à la plus courte. Dans le cas contraire, les directives dont l'URL constitue une partie du début de l'URL de directives apparaissant plus loin dans la configuration vont occulter ces dernières. Notez que tout ceci est en relation avec le partage de worker.

Pour les mêmes raisons, les exclusions doivent apparaître avant les directives `ProxyPass` générales.

Depuis la version 2.1 du serveur HTTP Apache, mod_proxy supporte les jeux de connexions vers un serveur d'arrière-plan. Ainsi, les connexions créées à la demande peuvent être conservées dans un jeu pour une utilisation ultérieure. Les limites de la taille du jeu de connexions et d'autres paramètres peuvent être définis au niveau de la directive `ProxyPass` via des arguments `clé=valeur` décrits dans la table ci-dessous.

Par défaut, mod_proxy permettra de conserver le nombre maximum de connexions pouvant être utilisées simultanément par le processus enfant concerné du serveur web. Vous pouvez utiliser le paramètre `max` pour réduire ce nombre par rapport à la valeur par défaut. Vous pouvez aussi utiliser le paramètre `ttl` pour définir une durée de vie optionnelle ; ainsi, les connections qui n'ont pas été utilisées au bout de `ttl` secondes seront fermées. Le paramètre `ttl` permet aussi d'empêcher l'utilisation d'une connexion susceptible d'être fermée suite à l'expiration de la durée de vie des connexions persistantes sur le serveur d'arrière-plan.

Le jeu de connexions est maintenu au niveau de chaque processus enfant du serveur web, et `max` et les autres paramètres ne font l'objet d'aucune coordination entre les différents processus enfants, sauf bien sur dans le cas où un seul processus enfant est permis par la configuration du module multiprocessus.

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

Paramètre | Défaut | Description
--- | --- | ---
min | 0 | Nombre minimum d'entrées dans le jeu de connexions, sans rapport avec le nombre réel de connexions. Ne doit être modifié par rapport à la valeur par défaut que dans des circonstances spéciales où la mémoire du tas associée aux connexions d'arrière-plan doit être préallouée ou conservée.
max | 1...n | Nombre maximum de connexions permises vers le serveur d'arrière-plan. La valeur par défaut pour cette limite est le nombre de threads par processus pour le module multiprocessus actif. Pour le MPM Prefork, la valeur est toujours 1, alors que pour les autres, on peut la contrôler via la directive `ThreadsPerChild`.

smax

max

Les entrées conservées du jeu de connexions au dessus de cette limite sont libérées au cours de certaines opérations si elles n'ont pas été utilisées au bout de leur durée de vie définie par le paramètre `ttl`. Si l'entrée du jeu de connexions est associée à une connexion, cette dernière sera alors fermée. Ce paramètre ne doit être modifié par rapport à la valeur par défaut que dans des circonstances spéciales où les entrées du jeu de connexions, et toutes connexions associées qui ont dépassé leur durée de vie doivent être respectivement libérées ou fermées plus impérativement.

acquire | - | 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 renverra l'état `SERVER_BUSY` au client.
connectiontimeout | timeout | Délai d'attente d'une connexion en secondes. La durée en secondes pendant laquelle Apache 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.

disablereuse

Off

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 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é à `On`.

flushpackets

off

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

flushwait | 10 | Le délai d'attente pour une entrée additionnelle, en millisecondes, avant le vidage du tampon en sortie dans le cas où 'flushpackets' est à 'auto'.

keepalive

Off

Cette clé doit être utilisée lorsque vous avez un pare-feu entre Apache httpd et le serveur d'arrière-plan, et si ce dernier tend à interrompre les connexions inactives. Cette clé va faire en sorte que le système d'exploitation envoie des messages `KEEP_ALIVE` sur chacune des connexions inactives et ainsi éviter la fermeture de la connexion par le pare-feu. Pour conserver les connexions persistantes, definissez cette propriété à `On`.

La fréquence de vérification des connexions TCP persistantes initiale et subséquentes dépend de la configuration globale de l'OS, et peut atteindre 2 heures. Pour être utile, la fréquence configurée dans l'OS doit être inférieure au seuil utilisé par le pare-feu.

lbset | 0 | Définit le groupe de répartition de charge dont le serveur cible est membre. Le répartiteur de charge va essayer tous les membres d'un groupe de répartition de charge de numéro inférieur avant d'essayer ceux dont le groupe possède un numéro supérieur.

ping

0

Avec la clé ping, le serveur web envoie une requête `CPING` sur la connexion ajp13 avant de rediriger une requête. La valeur correspond au délai d'attente de la réponse `CPONG`. Cette fonctionnalité a été ajoutée afin de pallier aux problèmes de blocage et de surcharge des serveurs Tomcat, et nécessite le support de ping/pong ajp13 qui a été implémenté dans Tomcat 3.3.2+, 4.1.28+ et 5.0.13+. Le trafic réseau peut s'en trouver augmenté en fonctionnement normal, ce qui peut poser problème, mais peut s'en trouver diminué dans les cas où les noeuds de cluster sont arrêtés ou surchargés. Cette clé n'est actuellement utilisable qu'avec AJP. Le délai peut aussi être défini en millisecondes en ajoutant le suffixe ms.

loadfactor | 1 | Facteur de charge du serveur cible à utiliser avec les membres d'un groupe de répartition de charge. Il s'agit d'un nombre entre 1 et 100 définissant le facteur de charge appliqué au serveur cible.
redirect | - | Route pour la redirection du serveur cible. Cette valeur est en général définie dynamiquement pour permettre une suppression sécurisée du noeud du cluster. Si cette clé est définie, toutes les requêtes sans identifiant de session seront redirigées vers le membre de groupe de répartition de charge dont la route correspond à la valeur de la clé.

retry

60

Délai entre deux essais du serveur cible du jeu de connexions en secondes. Si le serveur cible du jeu de connexions vers le serveur d'arrière-plan est dans un état d'erreur, Apache ne redirigera pas de requête vers ce serveur avant l'expiration du délai spécifié. Ceci permet d'arrêter le serveur d'arrière-plan pour maintenance, et de le remettre en ligne plus tard. Une valeur de 0 signifie toujours essayer les serveurs cibles dans un état d'erreur sans délai.

route | - | La route du serveur cible lorsqu'il est utilisé au sein d'un répartiteur de charge. La route est une valeur ajoutée à l'identifiant de session.

status

-

Valeur constituée d'une simple lettre et définissant l'état initial de ce serveur cible : 'D' correspond à "désactivé", 'S' à "arrêté", 'I' à "erreurs ignorées", 'H' à "interruption à chaud" et 'E' à "erreur". Une valeur d'état peut être définie (ce qui correspond au comportement par défaut) en préfixant la valeur par '+', ou annulée en préfixant la valeur par '-'. Ainsi, la valeur 'S-E' définit l'état de ce serveur cible à "arrêté" et supprime le drapeau "en-erreur".

timeout | `ProxyTimeout` | Délai d'attente de la connexion en secondes. Le nombre de secondes pendant lesquelles Apache attend l'envoi de données vers le serveur d'arrière-plan.
ttl | - | Durée de vie des connexions inactives et des entrées associées du jeu de connexions. Lorsque cette limite est atteinte, la connexion concernée ne sera plus utilisée ; elle sera ensuite fermée au bout d'un certain temps.

Si l'URL de la directive `ProxyPass` débute par `balancer://` (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` pour plus d'informations à propos du fonctionnement du répartiteur de charge.

Paramètre | Défaut | Description
--- | --- | ---

lbmethod

byrequests

Méthode de répartition de charge utilisée. Permet de sélectionner la méthode de planification de la répartition de charge à utiliser. La valeur est soit `byrequests`, pour effectuer un décompte de requêtes pondérées, soit `bytraffic`, pour effectuer une répartition en fonction du décompte des octets transmis, soit `bybusyness` (à partir de la version 2.2.10 du serveur HTTP Apache), pour effectuer une répartition en fonction des requêtes en attente. La valeur par défaut est `byrequests`.

maxattempts | 1 de moins que le nombre de workers, ou 1 avec un seul worker | Nombre maximum d'échecs avant abandon.
nofailover | Off | Si ce paramètre est défini à `On`, la session va s'interrompre si le serveur cible est dans un état d'erreur ou désactivé. Définissez ce paramètre à On si le serveur d'arrière-plan ne supporte pas la réplication de session.

stickysession

-

Nom de session persistant du répartiteur. La valeur est généralement du style `JSESSIONID` ou `PHPSESSIONID`, et dépend du serveur d'application d'arrière-plan qui supporte les sessions. Si le serveur d'application d'arrière-plan utilise des noms différents pour les cookies et les identifiants codés d'URL (comme les conteneurs de servlet), séparez-les par le caractère '|'. La première partie contient le cookie et la seconde le chemin.

scolonpathdelim | Off | Si ce paramètre est défini à `On`, le caractère ';' sera utilisé comme séparateur de chemin de session persistante additionnel. Ceci permet principalement de simuler le comportement de mod_jk lorsqu'on utilise des chemins du style `JSESSIONID=6736bcf34;foo=aabfa`.
timeout | 0 | Délai du répartiteur en secondes. Si ce paramètre est défini, sa valeur correspond à la durée maximale d'attente pour un serveur cible libre. Le comportement par défaut est de ne pas attendre.
failonstatus | - | Un code ou une liste de codes d'état HTTP séparés par des virgules. S'il est défini, ce paramètre va forcer le worker dans un état d'erreur lorsque le serveur d'arrière-plan retounera un code d'état spécifié dans la liste. Le rétablissement du worker est le même qu'avec les autres erreurs de worker. Disponible à partir de la version 2.2.17 du serveur HTTP Apache.

forcerecovery

On

Force la récupération immédiate de tous les membres du répartiteur sans tenir compte de leur paramètre de nouvel essai si tous les membres du répartiteur sont dans un état d'erreur. Dans certains cas cependant, un serveur d'arrière-plan déjà surchargé peut voir ses problèmes s'aggraver si la récupération de tous les membres du répartiteur est forcée sans tenir compte de leur paramètre de nouvel essai. Dans ce cas, définissez ce paramètre à `Off`. Disponible depuis la version 2.2.23 du serveur HTTP Apache.

Exemple de configuration d'un répartiteur

`ProxyPass /zone-speciale http://special.example.com smax=5 max=10
ProxyPass / balancer://mon-cluster/ stickysession=JSESSIONID|jsessionid nofailover=On
<Proxy balancer://mon-cluster>
BalancerMember ajp://1.2.3.4:8009
BalancerMember ajp://1.2.3.5:8009 loadfactor=20
# Serveur moins puissant ; faites-lui traiter moins de requêtes,
BalancerMember ajp://1.2.3.6:8009 loadfactor=5
</Proxy>`

Configuration d'un serveur cible de réserve qui ne sera utilisé que si aucun autre serveur cible n'est disponible

`ProxyPass / balancer://hotcluster/
<Proxy balancer://hotcluster>
BalancerMember ajp://1.2.3.4:8009 loadfactor=1
BalancerMember ajp://1.2.3.5:8009 loadfactor=2
# La ligne suivante configure le serveur cible de réserve
BalancerMember ajp://1.2.3.6:8009 status=+H
ProxySet lbmethod=bytraffic </Proxy>`

Normalement, mod_proxy va mettre sous leur forme canonique les URLs traitées par ProxyPass. Mais ceci peut être incompatible avec certains serveurs d'arrière-plan, et en particulier avec ceux qui utilisent PATH_INFO. Le mot-clé optionnel nocanon modifie ce comportement et permet de transmettre le chemin d'URL sous sa forme brute au serveur d'arrière-plan. Notez que 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.

Le mot-clé optionnel interpolate (disponible depuis httpd 2.2.9), en combinaison avec la directive `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` pour des règles complexes.

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

Cette directive ne peut pas être placée dans une section `<Directory>` ou `<Files>`.

Si vous avez besoin d'un configuration de mandataire inverse plus souple, reportez-vous à la documentaion de la directive `RewriteRule` et son drapeau `[P]`.

## ProxyPassInterpolateEnv Directive

Description: | Active l'interpolation des variables d'environnement dans les configurations de mandataires inverses
Syntaxe: | `ProxyPassInterpolateEnv On|Off`
Défaut: | `ProxyPassInterpolateEnv Off`
Contexte: | configuration du serveur, serveur virtuel, répertoire
Statut: | Extension
Module: | mod_proxy
Compatibilité: | Disponible depuis la version 2.2.9 d'Apache

Cette directive, ainsi que l'argument interpolate des directives `ProxyPass`, `ProxyPassReverse`, `ProxyPassReverseCookieDomain` et `ProxyPassReverseCookiePath`, 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`. Elle affecte les directives `ProxyPass`, `ProxyPassReverse`, `ProxyPassReverseCookieDomain`, et `ProxyPassReverseCookiePath`, en leur indiquant de remplacer la chaîne `${nom_var}` dans les directives de configuration par la valeur de la variable d'environnement `nom_var` (si l'option interpolate est spécifiée).

Conservez cette directive à off (pour les performances du serveur), sauf si vous en avez réellement besoin.

## ProxyPassMatch Directive

Description: | Fait correspondre des serveurs distants dans l'espace d'URL du serveur local en utilisant des expressions rationnelles
Syntaxe: | `ProxyPassMatch [regex] !|url [clé=valeur [clé=valeur ...]]`
Contexte: | configuration du serveur, serveur virtuel, répertoire
Statut: | Extension
Module: | mod_proxy
Compatibilité: | Disponible depuis la version 2.2.5 d'Apache

Cette directive est identique à la directive `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.

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

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

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

### Note

L'argument URL doit pouvoir être interprété en tant qu'URL avant les substitutions d'expressions rationnelles (et doit aussi l'être après). Ceci limite les correspondances que vous pouvez utiliser. Par exemple, si l'on avait utilisé

`ProxyPassMatch ^(/.*\.gif)$ http://backend.example.com:8000$1`

dans l'exemple précédent, nous aurions provoqué une erreur de syntaxe au démarrage du serveur. C'est une bogue (PR 46665 dans ASF bugzilla), et il est possible de la contourner en reformulant la correspondance :

`ProxyPassMatch ^/(.*\.gif)$ http://backend.example.com:8000/$1`

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

Lorsque cette directive se situe à l'intérieur d'une section `<LocationMatch>`, le premier argument est omis et l'expression rationnelle est obtenue à partir de la directive `<LocationMatch>`.

Si vous avez besoin d'une configuration de mandataire inverse plus flexible, reportez-vous à la directive `RewriteRule` avec le drapeau `[P]`.

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

## ProxyPassReverse Directive

Description: | Ajuste l'URL dans les en-têtes de la réponse HTTP envoyée par un serveur mandaté en inverse
Syntaxe: | `ProxyPassReverse [chemin] url [interpolate]`
Contexte: | configuration du serveur, serveur virtuel, répertoire
Statut: | Extension
Module: | mod_proxy

Cette directive permet de faire en sorte qu'Apache ajuste l'URL dans les en-têtes `Location`, `Content-Location` et `URI` des réponses de redirection HTTP. Ceci est essentiel lorsqu'Apache 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 ne réécrira ni les autres en-têtes de réponse, ni 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. Le module mod_proxy_html de Nick Kew est un module tiers qui parcourt le code HTML et réécrit les références d'URL.

chemin est le nom d'un chemin virtuel local. url est une URL partielle pour le serveur distant - ils sont utilisés de la même façon qu'avec la directive `ProxyPass`.

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

`ProxyPass /miroir/foo/ http://backend.example.com/
ProxyPassReverse /miroir/foo/ http://backend.example.com/
ProxyPassReverseCookieDomain backend.example.com public.example.com
ProxyPassReverseCookiePath / /miroir/foo/`

ne va pas seulement provoquer la conversion interne d'une requête locale pour `http://example.com/miroir/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 serveur `backend.example.com` envoie : lorsque `http://backend.example.com/bar` est redirigé par celui-ci vers `http://backend.example.com/quux`, Apache corrige ceci en `http://example.com/miroir/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`.

Notez que la directive `ProxyPassReverse` peut aussi être utilisée en conjonction avec la fonctionnalité pass-through (`RewriteRule ... [P]`) du module `mod_rewrite`, car elle ne dépend pas d'une directive `ProxyPass` correspondante.

Le mot-clé optionnel interpolate (disponible depuis httpd 2.2.9), utilisé en combinaison avec la directive `ProxyPassInterpolateEnv`, permet l'interpolation des variables d'environnement spécifiées en utilisant le format ${VARNAME}.

Lorsque cette directive est utilisée dans une section `<Location>`, le premier argument est omis et le répertoire local est obtenu à partir de l'argument de la directive `<Location>`. Il en est de même à l'intérieur d'une section `<LocationMatch>`, mais le résultat ne correspondra probablement pas à ce que vous attendez, car ProxyPassReverse interprète l'expression rationnelle littéralement comme un chemin ; si nécessaire dans cette situation, spécifiez la directive ProxyPassReverse en dehors de la section, ou dans une section `<Location>` séparée.

Cette directive ne peut pas être placée dans une section `<Directory>` ou `<Files>`.

## ProxyPassReverseCookieDomain Directive

Description: | Ajuste la chaîne correspondant au domaine dans les en-têtes Set-Cookie en provenance d'un serveur mandaté
Syntaxe: | `ProxyPassReverseCookieDomain domaine-interne domaine-public [interpolate]`
Contexte: | configuration du serveur, serveur virtuel, répertoire
Statut: | Extension
Module: | mod_proxy

L'utilisation de cette directive est similaire à celle de la directive `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êtes `Set-Cookie`.

## ProxyPassReverseCookiePath Directive

Description: | Ajuste la chaîne correspondant au chemin dans les en-têtes Set-Cookie en provenance d'un serveur mandaté
Syntaxe: | `ProxyPassReverseCookiePath chemin-interne chemin-public [interpolate]`
Contexte: | configuration du serveur, serveur virtuel, répertoire
Statut: | Extension
Module: | mod_proxy

Cette directive s'avère utile en conjonction avec la directive `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êtes `Set-Cookie`. Si le début du chemin du cookie correspond à chemin-interne, le chemin du cookie sera remplacé par chemin-public.

Dans l'exemple fourni avec la directive `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/`..

## ProxyPreserveHost Directive

Description: | Utilise l'en-tête de requête entrante Host pour la requête du mandataire
Syntaxe: | `ProxyPreserveHost On|Off`
Défaut: | `ProxyPreserveHost Off`
Contexte: | configuration du serveur, serveur virtuel
Statut: | Extension
Module: | mod_proxy
Compatibilité: | Disponible depuis la version 2.0.31 d'Apache.

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

## ProxyReceiveBufferSize Directive

Description: | Taille du tampon réseau pour les connexions mandatées HTTP et FTP
Syntaxe: | `ProxyReceiveBufferSize octets`
Défaut: | `ProxyReceiveBufferSize 0`
Contexte: | configuration du serveur, serveur virtuel
Statut: | Extension
Module: | mod_proxy

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`

## ProxyRemote Directive

Description: | Mandataire distant à utiliser pour traiter certaines requêtes
Syntaxe: | `ProxyRemote comparaison serveur-distant`
Contexte: | configuration du serveur, serveur virtuel
Statut: | Extension
Module: | mod_proxy

Cette directive permet de définir des mandataires distants pour ce mandataire. comparaison 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. serveur-distant est une URL partielle correspondant au serveur distant. Syntaxe :

`serveur-distant = protocole://nom-serveur[:port]`

protocole est effectivement le protocole à utiliser pour communiquer avec le serveur distant ; ce module ne supporte que `http` et `https`. Avec `https`, les requêtes sont transmises par le mandataire distant via la méthode HTTP CONNECT.

### Exemple

`ProxyRemote http://bons-gars.example.com/ http://gars-mirroirs.example.com:8000
ProxyRemote * http://mandataire-intelligent.localdomain
ProxyRemote ftp http://mandataire-ftp.mon-domaine: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.

## ProxyRemoteMatch Directive

Description: | Le mandataire distant à utiliser pour traiter les requêtes correspondant à une expression rationnelle
Syntaxe: | `ProxyRemoteMatch regex serveur-distant`
Contexte: | configuration du serveur, serveur virtuel
Statut: | Extension
Module: | mod_proxy

La directive `ProxyRemoteMatch` est identique à la directive `ProxyRemote`, à l'exception que le premier argument est une expression rationnelle à mettre en correspondance avec l'URL de la requête.

## ProxyRequests Directive

Description: | Active la fonctionnalité (standard) de mandataire direct
Syntaxe: | `ProxyRequests On|Off`
Défaut: | `ProxyRequests Off`
Contexte: | configuration du serveur, serveur virtuel
Statut: | Extension
Module: | mod_proxy

Cette directive permet d'activer/désactiver la fonctionnalité de serveur mandataire direct d'Apache. Définir ProxyRequests à `Off` n'interdit pas l'utilisation de la directive `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` et/ou `mod_proxy_ftp` doivent aussi être chargés dans le serveur.

`mod_proxy_connect` doit être activé pour pouvoir mandater (en direct) des sites HTTPS.

### Avertissement

N'activez pas la fonctionnalité de mandataire avec la directive `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

## ProxySet Directive

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
Syntaxe: | `ProxySet url clé=valeur [clé=valeur ...]`
Contexte: | répertoire
Statut: | Extension
Module: | mod_proxy
Compatibilité: | ProxySet n'est disponible que depuis la version 2.2 d'Apache.

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éfini via la directive `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` au lieu de `ProxyPass`.

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

`<Proxy http://backend>
ProxySet keepalive=On
</Proxy>`

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

## ProxyStatus Directive

Description: | Affiche l'état du répartiteur de charge du mandataire dans mod_status
Syntaxe: | `ProxyStatus Off|On|Full`
Défaut: | `ProxyStatus Off`
Contexte: | configuration du serveur, serveur virtuel
Statut: | Extension
Module: | mod_proxy
Compatibilité: | Disponible depuis la version 2.2 d'Apache

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

### Note

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

## ProxyTimeout Directive

Description: | Délai d'attente réseau pour les requêtes mandatées
Syntaxe: | `ProxyTimeout secondes`
Défaut: | `Valeur de la directive `Timeout``
Contexte: | configuration du serveur, serveur virtuel
Statut: | Extension
Module: | mod_proxy
Compatibilité: | Disponible depuis la version 2.0.31 d'Apache

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.

## ProxyVia Directive

Description: | Information fourni dans l'en-tête de réponse HTTP `Via` pour les requêtes mandatées
Syntaxe: | `ProxyVia On|Off|Full|Block`
Défaut: | `ProxyVia Off`
Contexte: | configuration du serveur, serveur virtuel
Statut: | Extension
Module: | mod_proxy

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ête `Via:`.

- 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ête `Via:` se verra ajouter la version du serveur Apache 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é.

Langues Disponibles: en | fr | ja

## Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.