Module Apache mod_proxy

Directive BalancerGrowth ¶

Cette directive permet de définir le nombre de répartiteurs de charge pouvant être ajoutés à ceux déjà configurés pour un serveur virtuel. Elle n'est active que si au minimum un répartiteur a été préconfiguré.

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.

La désactivation de ProxyPassInherit désactive aussi la directive BalancerInherit.

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.

La directive BalancerMember accepte un paramètre supplémentaire : loadfactor. Il s'agit du facteur de charge du membre - un nombre 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 <Proxy balancer://...>. Il correspond à l'URL d'un répartiteur de charge défini par une directive ProxyPass.

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

Les slashes de fin doivent normalement être supprimés de l'URL d'un BalancerMember.

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

ProxyRemote  *  http://firewall.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 .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 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 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.

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.edu
www.example.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 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 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

Directive <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 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
</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>

Dans l'exemple suivant, les clients web possédant l'adresse IP spécifiée seront autorisés à effectuer des requêtes CONNECT pour accéder au serveur https://www.example.com/, sous réserve que le module mod_proxy_connect soit chargé.

<Proxy www.example.com:443>
  Require ip 192.168.0.0/16
</Proxy>

Voir aussi

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

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.

Directive ProxyBadHeader ¶

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.

Directive ProxyBlock ¶

La directive ProxyBlock permet d'interdire l'accès FTP ou HTTP via le mandataire à certains hôtes en fonction d'une correspondance exacte ou partielle avec un nom d'hôte, ou dans la mesure du possible en fonction d'une comparaison d'adresses IP.

Chaque paramètre de la directive ProxyBlock accepte comme valeur soit *, soit une chaîne alphanumérique. Au démarrage, le module tente de résoudre toute chaîne alphanumérique depuis un nom DNS vers un jeu d'adresses IP, mais toute erreur de DNS est ignorée.

Si un paramètre a pour valeur "*", mod_proxy interdira l'accès à tout site FTP ou HTTP.

Dans le cas contraire, pour toute requête vers une ressource FTP ou HTTP via le mandataire, mod_proxy va comparer le nom d'hôte de l'URI de la requête avec chaque chaîne alphanumérique spécifiée. Si une chaîne correspond, même partiellement, l'accès est refusé. Si aucune chaîne ne correspond, et si un mandataire distant (forward) est configuré via la directive ProxyRemote ou ProxyRemoteMatch, l'accès est autorisé. Si aucun mandataire distant (forward) n'est configuré, l'adresse IP correspondant au nom d'hôte de l'URI est comparée à toutes les adresses IP résolues au démarrage, et l'accès est refusé si une correspondance est trouvée.

Notez que les recherches DNS peuvent ralentir le processus de démarrage du serveur.

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

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

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.

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'attribut packetSize de votre connecteur AJP du côté de Tomcat ! L'attribut packetSize n'est disponible que dans Tomcat 5.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 <ProxyMatch> ¶

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.

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. 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://(?<sitename>[^/]+)>
    require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
</ProxyMatch>

Voir aussi

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

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

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

Les sockets de style Unix sont supportés à partir de la version 2.4.7 du serveur HTTP Apache ; pour utiliser cette fonctionnalité, il suffit d'utiliser une URL cible préfixée par unix:/path/lis.sock|. Par exemple, pour mandater HTTP et cibler l'UDS /home/www.socket, vous devez utiliser unix:/home/www.socket|http://localhost/whatever/. Comme le socket est local, le nom d'hôte utilisé (ici localhost) peut être sujet à discussion, mais il est transmis dans l'en-tête Host: de la requête.

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 sera de même dans une section <LocationMatch> ; cependant, ProxyPass n'interprète pas les expressions rationnelles, et il sera ici nécessaire d'utiliser la directive ProxyPassMatch à la place.

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

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

va convertir en interne toute requête pour http://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 documentation de la directive 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/"

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>
<Location "/mirror/foo/i">
    ProxyPass "!"
</Location>

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/"
</Location>

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

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ètres clé=valeur dont la description fait l'objet du tableau ci-dessous.

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

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

ProxyPass "/special%3Fsegment" "https://example.com/special%3Fsegment" mapping=encoded

<Location "/special%3Fsegment">
  Require ip 172.17.2.0/24
</Location>

ProxyPass "/some/path" "https://servlet.example.com/some/path" mapping=servlet

<Location "/some/path">
  Require valid-user
</Location>

Si l'URL de la directive Proxy 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.

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
    # Le serveur suivant est moins puissant ; on lui envoie moins de requêtes,
    BalancerMember ajp://1.2.3.6:8009 loadfactor=5
</Proxy>

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
</Proxy>

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
    # Le serveur suivant est en mode hot standby
    BalancerMember ajp://1.2.3.6:8009 status=+H
    ProxySet lbmethod=bytraffic
</Proxy>

Mot-clés supplémentaires 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é 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 ce mot-clé peut affecter la sécurité de votre serveur d'arrière-plan, car la protection limitée contre les attaques à base d'URL que fournit le mandataire est alors supprimée.

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

Le mot-clé optionnel interpolate, 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. Notez aussi que l'interpolation n'est supportée dans la partie protocole/hostname/port d'une URL que pour les variables qui sont accessibles au moment où la directive est interprétée (similairement à la directive Define). La détermination dynamique de ces champs peut être effectuée à l'aide de mod_rewrite. L'exemple suivant décrit comment utiliser mod_rewrite 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/"

Directive ProxyPassInherit ¶

Cette directive permet à un serveur virtuel d'hériter des directives 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.

Directive ProxyPassInterpolateEnv ¶

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.

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). Pour tous les autres cas, utilisez plutôt mod_rewrite.

Directive ProxyPassMatch ¶

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.

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

Dans 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 du mandataire inverse plus flexible, voyez la directive RewriteRule avec le drapeau [P].

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.

chemin est le nom d'un chemin virtuel local. Il est combiné avec le protocole, le nom d'hôte et le port pour former le préfixe de remplacement de l'en-tête de réponse concerné. Ce paramètre est en général identique au premier paramètre de la directive ProxyPass.

url est une URL partielle pour le serveur distant. Lorsque le serveur distant envoie les en-têtes explicitement mentionnés en commençant par cette URL partielle, le préfixe du serveur distant est remplacé par un préfixe qui pointe vers le mandataire inverse. Ce paramètre est en général identique au second paramètre de la directive ProxyPass, mais il peut être différent si le serveur distant utilise un protocole, nom d'hôte, port ou chemin différent dans les en-têtes concernés. Si la configuration contient une directive ProxyPreserveHost, le nom d'hôte de l'URL partielle correspondra peut-être déjà au nom d'hôte du mandataire inverse, ce qui évitera la recherche et le remplacament effectués par cette directive.

Supposons par exemple que le serveur local a pour adresse http://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 serveur backend.example.com envoie lorsque http://backend.example.com/bar est redirigé par celui-ci vers http://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.

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

Le mot-clé optionnel interpolate, utilisé en combinaison avec la directive 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>, 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 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> séparée.

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

Directive ProxyPassReverseCookieDomain ¶

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.

Directive ProxyPassReverseCookiePath ¶

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

Directive ProxyPreserveHost ¶

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.

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.

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 :

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

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

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 é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 doit également être chargé dans le serveur.

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

Directive ProxySourceAddress ¶

Cette directive permet de définir une adresse IP locale spécifique à laquelle faire référence lors d'une connexion à un serveur d'arrière-plan.

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.

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