Module Apache mod_proxy

NoteEn plus du nombre à usage unique, la page de l'application

Less powerful server, don't send as many requests there, BalancerMember ajp://1.2.3.6:8009 loadfactor=5

The server below is on hot standby BalancerMember ajp://1.2.3.6:8009 status=+H ProxySet lbmethod=bytraffic

avant d'avoir ProxyRequestssécurisé votre serveur. Les serveurs mandataires ouverts sont dangereux pour votre réseau, mais aussi pour l'Internet au sens large.

et ses modules associés implémentent un mandataire/passerelle pour le serveur HTTP Apache, et supportent de nombreux protocoles courants, ainsi que plusieurs algorithmes de répartition de charge. Le support de protocoles et d'algorithmes de répartition de charge supplémentaires peut être assuré par des modules tiers.mod_proxy

Un jeu de modules chargés dans le serveur permet de fournir les fonctionnalités souhaitées. Ces modules peuvent être inclus statiquement à la compilation, ou dynamiquement via la directive

. Ce jeu de module doit comporter :LoadModule

, qui fournit les fonctionnalités de base d'un mandatairemodproxybalancer

pour plus de détails).| Protocole | Module | |---|---| | AJP13 (Protocole Apache JServe version 1.3) | | | CONNECT (pour SSL) | | | FastCGI | | | ftp | | | HTTP/0.9, HTTP/1.0, et HTTP/1.1 | | | SCGI | | | WS and WSS (Web-sockets) | |

En outre, d'autres modules fournissent des fonctionnalités étendues.

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

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

. 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 ProxyRequestssécuriser votre serveur de façon à ce que seuls les clients autorisés puissent accéder à votre serveur avant d'activer la fonctionnalité de mandataire direct.

Un mandataire inverse (ou passerelle), quant à lui, apparaît au client comme un serveur web standard. Aucune configuration particulière du client n'est nécessaire. Le client adresse ses demandes de contenus ordinaires dans l'espace de nommage du mandataire inverse. Ce dernier décide alors où envoyer ces requêtes, et renvoie le contenu au client comme s'il l'hébergeait lui-même.

L'accès d'utilisateurs depuis Internet vers un serveur situé derrière un pare-feu est une utilisation typique du mandataire inverse. On peut aussi utiliser les mandataires inverses pour mettre en oeuvre une répartition de charge entre plusieurs serveurs en arrière-plan, ou fournir un cache pour un serveur d'arrière-plan plus lent. Les mandataires inverses peuvent aussi tout simplement servir à rassembler plusieurs serveurs dans le même espace de nommage d'URLs.

Si en outre, vous désirez activer la mise en cache, consultez la documentation de

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

ProxyRequests On ProxyVia On Require host internal.example.com

Vous pouvez aussi forcer le traitement d'une requête en tant que requête de mandataire inverse en créant un gestionnaire de transfert approprié. Dans l'exemple suivant, toutes les requêtes pour des scripts PHP seront transmises au serveur FastCGI spécifié via un mandat inverse :

SetHandler "proxy:unix:/path/to/app.sock|fcgi://localhost/"

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

Les deux workers par défaut possèdent une configuration figée et seront utilisés si aucun autre worker ne correspond à la requête. Ils n'utilisent ni les jeux de connexions (connection pooling), ni les connexions HTTP persistantes (Keep-Alive). En effet, les connexions TCP vers le serveur original sont fermées et ouvertes pour chaque requête.

Les workers définis explicitement sont identifiés par leur URL. Ils sont en général définis via les directives

lorsqu'on les utilise dans le cadre d'un mandataire inverse :ProxyPassMatch

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

L'utilisation de workers définis explicitement dans le mode mandataire direct n'est pas très courante, car les mandataires directs communiquent en général avec de nombreux serveurs originaux. La création explicite de workers pour certains serveurs originaux peut cependant s'avérer utile si ces serveurs sont très souvent sollicités. A leur niveau, les workers explicitement définis ne possèdent aucune notion de mandataire direct ou inverse. Ils encapsulent un concept de communication commun avec les serveurs originaux. Un worker créé via la directive

pour être utilisé dans le cadre d'un mandataire inverse sera aussi utilisé dans le cadre d'un mandataire directe chaque fois que l'URL vers le serveur original correspondra à l'URL du worker, et vice versa.ProxyPass

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

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

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

Le partage de workers intervient lorsque les URLs des workers s'entrecoupent, ce qui arrive lorsque l'URL d'un worker correspond au début de l'URL d'un autre worker défini plus loin dans le fichier de configuration. Dans l'exemple suivant,

le second worker n'est pas vraiment créé. C'est le premier worker qui est en fait utilisé. L'avantage de ceci réside dans le fait qu'il n'existe qu'un seul jeu de connexions, ces dernières étant donc réutilisées plus souvent. Notez que tous les attributs de configuration définis explicitement pour le deuxième worker seront ignorés, ce qui sera journalisé en tant qu'avertissement. Ainsi, dans l'exemple ci-dessus, la valeur de timeout retenue pour l'URL /exemples

Si vous voulez empêcher le partage de workers, classez vos définitions de workers selon la longueur des URLs, de la plus longue à la plus courte. Si au contraire vous voulez favoriser ce partage, utilisez l'ordre de classement inverse. Voir aussi l'avertissement à propos de l'ordre de classement des directives

Les workers définis explicitement sont de deux sortes : workers directs et workers de répartition (de charge). Ils supportent de nombreux attributs de configuration importants décrits dans la directive

Le jeu d'options disponibles pour un worker direct dépend du protocole spécifié dans l'URL du serveur original. Les protocoles disponibles comprennent ajp

Les workers de répartition sont des workers virtuels qui utilisent les workers directs, connus comme faisant partie de leurs membres, pour le traitement effectif des requêtes. Chaque répartiteur peut comporter plusieurs membres. Lorsqu'il traite une requête, il choisit un de ses membres en fonction de l'algorithme de répartition de charge défini.

comme indicateur de protocole. L'URL du répartiteur permet d'identifier de manière unique le worker de répartition. La directive

Restreindre l'accès de manière stricte est essentiel si vous mettez en oeuvre un mandataire direct (en définissant la directive

à "on"). Dans le cas contraire, votre serveur pourrait être utilisé par n'importe quel client pour accéder à des serveurs quelconques, tout en masquant sa véritable identité. Ceci représente un danger non seulement pour votre réseau, mais aussi pour l'Internet au sens large. Dans le cas de la mise en oeuvre d'un mandataire inverse (en utilisant la directive ProxyRequests

), le contrôle d'accès est moins critique car les clients ne peuvent contacter que les serveurs que vous avez spécifiés.

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

de façon à ce qu'elle fasse suivre le ProxyRemoteprotocole 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

permet de spécifier quels hôtes appartiennent à l'Intranet et peuvent donc être accédés directement.NoProxy

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

est utilisée et si le serveur est ProxyDomainconfiguré comme mandataire, Apache httpd peut renvoyer une réponse de redirection et ainsi fournir au client l'adresse de serveur correcte, entièrement qualifiée. C'est la méthode à privilégier car le fichier des marque-pages de l'utilisateur contiendra alors des noms de serveurs entièrement qualifiés.

Il s'agit des variables force-proxy-request-1.0

ProxyPass http://buggyappserver:7001/foo/ SetEnv force-proxy-request-1.0 1 SetEnv proxy-nokeepalive 1

s'efforce toujours d'envoyer l'en-tête modproxyhttpContent-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

diminue la consommation de ressources en imposant l'utilisation d'un codage à fractionnement.

Dans certaines circonstances, le serveur doit mettre en file d'attente sur disque les corps de requêtes afin de satisfaire le traitement demandé des corps de requêtes. Par exemple, cette mise en file d'attente se produira si le corps original a été envoyé selon un codage morcelé (et possède une taille importante), alors que l'administrateur a demandé que les requêtes du serveur d'arrière-plan soient envoyées avec l'en-tête Content-Length ou en HTTP/1.0. Cette mise en file d'attente se produira aussi si le corps de la requête contient déjà un en-tête Content-Length, alors que le serveur est configuré pour filtrer les corps des requêtes entrantes.

Ces en-têtes doivent être utilisés avec précautions sur le serveur demandé, car ils contiendront plus d'une valeur (séparées par des virgules) si la requête originale contenait déjà un de ces en-têtes. Par exemple, vous pouvez utiliser %{X-Forwarded-For}i

dans la chaîne de format du journal du serveur demandé pour enregistrer les adresses IP des clients originaux, mais il est possible que vous obteniez plusieurs adresses si la requête passe à travers plusieurs mandataires.

Note : Si vous devez ajouter des en-têtes particuliers à la requête mandatée, utilisez la directive

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

L'argument balancerurl n'est requis que s'il ne se trouve pas dèjà dans la directive de conteneur

En particulier, le slash de fin de l'URL d'un BalancerMember

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 * http://firewall.example.com:81 NoProxy .example.com 192.168.112.0/21

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

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

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

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

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 :

255.255.0.0

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

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.

192.168.123.7

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

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

prep.ai.example.edu

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

seront traités par le filtre INCLUDES

Une URL d'arrière-plan sera concernée par le conteneur Proxy si elle commence par la url-avec-jokers, même si le dernier segment de chemin de la directive ne correspond qu'à un préfixe de segment dee chemin de l'URL d'arrière-plan. Par exemple, correspondra entre autres aux URLs http://example.com/foo, http://example.com/foo/bar, et http://example.com/foobar. La correspondance de l'URL finale diffère du comportement de la section

qui, pour le cas de cette note, traitera le segment de chemin final comme s'il se terminait par un slash.

Cette option n'est utile que dans le cas du mandat HTTP traité par

ProxyBadHeader IsError|Ignore|StartBody

ProxyBlock *|terme|serveur|domaine [terme|serveur|domaine] ...

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

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

suffirait aussi pour atteindre ces sites.

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

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

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

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

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.

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

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

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

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.

ProxyPass [chemin] !|url [clé=valeur [clé=valeur ...]] [nocanon] [interpolate] [noquery]

.Le support des sockets de style Unix est fourni ; il suffit pour cela 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/

tient compte de la directive DefaultRuntimeDir

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 :

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.

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

ProxyPass http://backend.example.com/ ProxyPass !

sont évaluées dans l'ordre de leur apparition dans le fichier de configuration. La première règle qui correspond s'applique. Vous devez donc en général classer les règles ProxyPassMatch

qui entrent en conflit de l'URL la plus longue à la plus courte. Dans le cas contraire, les règles situées après une règle dont l'URL correspond au début de leur propre URL seront ignorées. Notez que tout ceci est en relation avec le partage de workers. Par contre, on ne peut placer qu'une seule directive ProxyPass

Pour les mêmes raisons, les exclusions doivent se situer avant les directives ProxyPass

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

dont la description fait l'objet du tableau ci-dessous.

Par défaut, mod_proxy permet et met en réserve le nombre maximum de connexions pouvant être utilisées simultanément par le processus enfant concerné du serveur web. Le paramètre max

, 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

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.

, ainsi que les autres paramètres, ne font l'objet d'aucune coordination entre les différents processus enfants, sauf si un seul processus enfant est autorisé par la configuration ou la conception du module multi-processus (MPM).

| Paramètre | Défaut | Description | |||||| |---|---|---|---|---|---|---|---|---| | min | 0 | Nombre minimum d'entrées dans le pool de connexions, distinct du nombre de connexions effectif. La valeur par défaut ne doit être modifiée que dans des circonstances particulières où la mémoire associée aux connexions avec le serveur d'arrière-plan doit être préallouée ou réservée dans le tas. | |||||| | max | 1...n | Nombre maximum de connexions autorisées vers le serveur d'arrière-plan. La valeur par défaut correspond au nombre de threads par processus pour le MPM (Module Multi Processus) actif. La valeur sera toujours 1 pour le MPM Prefork, alors qu'elle dépendra de la définition de la directive ThreadsPerChild pour les autres MPMs. | |||||| | smax | max | Les entrées du pool de connexions conservées au delà de cette limite sont libérées au cours de certaines opérations si elles n'ont pas été utilisées au cours de leur durée de vie, définie par le paramètre ttl . Si l'entrée du pool de connexions est associée à une connexion, cette dernière sera fermée. La valeur par défaut ne doit être modifiée que dans des circonstances particulières où les entrées du pool de connexions et toutes connexions associées qui ont dépassé leur durée de vie doivent être libérées ou fermées de manière plus autoritaire. | |||||| | 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 httpd renverra l'état SERVERBUSY au client. | |||||| | connectiontimeout | timeout | Délai d'attente d'une connexion en secondes. La durée en secondes pendant laquelle Apache httpd va attendre pour l'établissement d'une connexion vers le serveur d'arrière-plan. Le délai peut être spécifié en millisecondes en ajoutant le suffixe ms. | |||||| | disablereuse | Off | Vous pouvez utiliser cette clé pour forcer modproxy à fermer immédiatement une connexion vers le serveur d'arrière-plan après utilisation, et ainsi désactiver le jeu de connexions permanentes vers ce serveur. Ceci peut s'avérer utile dans des situations où un pare-feu situé entre Apache httpd et le serveur d'arrière-plan (quelque soit le protocole) interrompt des connexions de manière silencieuse, ou lorsque le serveur d'arrière-plan lui-même est accessible par rotation de DNS (round-robin DNS). Pour désactiver la réutilisation du jeu de connexions, définissez cette clé à 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'. | |||||| | iobuffersize | 8192 | Permet de définir la taille du tampon d'entrées/sorties du bloc-notes interne. Cette clé vous permet d'outrepasser la directive ProxyIOBufferSize pour un serveur cible spécifique. La valeur doit être au minimum 512 ou définie à 0 pour la valeur par défaut du système de 8192. | |||||| | 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 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 va "tester" la connexion vers le serveur d'arrière-plan avant de transmettre la requête. Avec AJP, envoie une requête CPING sur la connexion ajp13 (implémenté sur Tomcat 3.3.2+, 4.1.28+ et 5.0.13+). Avec HTTP, envoie 100-Continue au serveur d'arrière-plan (seulement avecHTTP/1.1 - pour les serveurs d'arrière-plan non HTTP/1.1, cette clé ne produit aucun effet). Dans les deux cas, ce paramètre correspond au délai en secondes pour l'attente de la réponse. Cette fonctionnalité a été ajoutée pour éviter les problèmes avec les serveurs d'arrière-plan bloqués ou surchargés. 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. Le délai peut aussi être défini en millisecondes en ajoutant le suffixe ms. | |||||| | receivebuffersize | 0 | Définit la taille du tampon réseau explicite (TCP/IP) pour les connexions mandatées. Cette clé vous permet d'outrepasser la directive ProxyReceiveBufferSize pour un serveur cible spécifique. Sa valeur doit être au minimum 512 ou définie à 0 pour la valeur par défaut du système. | |||||| | 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 httpd 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 implique de 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. | |||||| | timeout | | Délai d'attente de la connexion en secondes. Le nombre de secondes pendant lesquelles Apache httpd 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 du pool de connexions associées en secondes. Une fois cette limite atteinte, une connexion ne sera pas réutilisée ; elle sera fermée après un délai variable. |

, 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

| 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 , 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.Disponible depuis la version 2.4.4 du serveur HTTP Apache. | | stickysessionsep | "." | Définit le caractère de séparation dans le cookie de session. Certains serveurs d'application d'arrière-plan n'utilisent pas le caractère '.' comme séparateur. Par exemple le serveur Oracle Weblogic utilise le caractère '!'. Cette option permet d'attribuer au caractère de séparation la valeur appropriée. Si elle est définie à 'Off', aucun caractère de séparation n'est utilisé. | | 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 | - | Une liste de codes d'état HTTP séparés par des virgules. Si ce paramètre est présent, le worker se mettra en erreur si le serveur d'arrière-plan renvoie un des codes d'état spécifiés dans la liste. La récupération du worker s'effectue comme dans le cas des autres erreurs de worker. | | failontimeout | Off | Si ce paramètre est défini à "On", un délai d'attente dépassé en entrée/sortie après envoi d'une requête au serveur d'arrière-plan va mettre le processus en état d'erreur. La sortie de cet état d'erreur se passe de la même façon que pour les autres erreurs. Disponible à partir de la version 2.4.5 du serveur HTTP Apache. | | nonce | | Le nombre à usage unique de protection utilisé dans la page de l'application balancer-manager . Par défaut, la protection de la page est assurée par un nombre à usage unique automatique à base d'UUID. Si une valeur est précisée, elle sera utilisée comme nombre à usage unique. La valeur None désactive la vérification du nombre à usage unique. ## NoteEn plus du nombre à usage unique, la page de l'application | | growth | 0 | Nombre de membres supplémentaires que l'on peut ajouter à ce répartiteur en plus de ceux définis au niveau de la configuration. | | forcerecovery | On | Force la relance immédiate de tous les membres sans tenir compte de leur paramètre retry dans le cas où ils sont tous en état d'erreur. Il peut cependant arriver qu'un membre déjà surchargé entre dans une situation critique si la relance de tous les membres est forcée sans tenir compte du paramètre retry de chaque membre. Dans ce cas, définissez ce paramètre à Off .Disponible depuis la version 2.4.2 du serveur HTTP Apache. |

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

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

Normalement, modproxy 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 PATHINFO. 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.

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

, le premier argument est omis et le répertoire local est obtenu à partir de la section

; cependant, ProxyPass n'interprète pas les expressions rationnelles, et il sera ici nécessaire d'utiliser la directive ProxyPassMatch

Si vous avez besoin d'un configuration de mandataire inverse plus souple, reportez-vous à la documentaion de la directive

et son drapeau RewriteRule[P]

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

pour des règles complexes. Notez aussi que l'interpolation n'est pas supportée dans la partie protocole d'une URL. La détermination dynamique du protocole peut être effectuée à l'aide de mod_rewrite

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/

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

, en leur indiquant de remplacer la chaîne ${nom_var}

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

va provoquer la conversion interne de la requête locale http://example.com/foo/bar.gif

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é

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 :

Si vous avez besoin d'une configuration du mandataire inverse plus flexible, voyez la directive

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.

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

est redirigé par celui-ci vers http://backend.example.com/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

peut aussi être utilisée en conjonction avec la fonctionnalité pass-through (RewriteRule ... [P]

, 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

. Si le début du chemin du cookie correspond à chemin-interne, le chemin du cookie sera remplacé par chemin-public.

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

protocole est effectivement le protocole à utiliser pour communiquer avec le serveur distant ; ce module ne supporte que http

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.

doivent également être chargés dans le serveur.modproxyftp

doit également être chargé dans le serveur.modproxyconnect

, l'argument url de répartiteur|url de serveur cible>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

BalancerMember http://www2.example.com:8080 loadfactor=1 BalancerMember http://www3.example.com:8080 loadfactor=2 ProxySet lbmethod=bytraffic

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.

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.

pour les requêtes mandatéesProxyVia On|Off|Full|Block

se verra ajouter la version du serveur Apache httpd sous la forme d'un champ de commentaire Via:

supprimées. Aucun nouvel en-tête Via:

Modules | Directives | FAQ | Glossaire | Plan du site

Serveur Apache HTTP Version 2.4