N'activez pas la fonctionnalité de mandataire avec la directive
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
| 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. SSLProxy*
du module
Le serveur HTTP 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
La fonctionnalité de mandataire direct est activée via la
directive
Un mandataire inverse (ou passerelle), quant à lui, apparaît au client comme un serveur web standard. Aucune configuration particulière du client n'est nécessaire. Le client adresse ses demandes de contenus ordinaires dans l'espace de nommage du mandataire inverse. Ce dernier décide alors où envoyer ces requêtes, et renvoie le contenu au client comme s'il l'hébergeait lui-même.
L'accès d'utilisateurs depuis Internet vers un serveur situé derrière un pare-feu est une utilisation typique du mandataire inverse. On peut aussi utiliser les mandataires inverses pour mettre en oeuvre une répartition de charge entre plusieurs serveurs en arrière-plan, ou fournir un cache pour un serveur d'arrière-plan plus lent. Les mandataires inverses peuvent aussi tout simplement servir à rassembler plusieurs serveurs dans le même espace de nommage d'URLs.
La fonctionnalité de mandataire inverse est activée via la
directive [P] de la directive
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
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 :
Cette fonctionnalité est disponible à partir de la version 2.4.10 du serveur HTTP Apache.
Le mandataire gère la configuration et les paramètres de communication des serveurs originaux au sein d'objets nommés workers. Deux types de worker sont fournis : le worker par défaut du mandataire direct et le worker par défaut du mandataire inverse. Il est aussi possible de définir explicitement des workers supplémentaires.
Les deux workers par défaut possèdent une configuration figée et seront utilisés si aucun autre worker ne correspond à la requête. Ils 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
Cette directive va créer un worker associé à l'URL du serveur
original http://backend.example.com, et utilisant les
valeurs de timeout données. Lorsqu'ils sont utilisés dans le cadre
d'un mandataire direct, les workers sont en général définis via la
directive
ou encore via les directives
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
L'URL qui identifie un worker correspond à l'URL de son serveur original, y compris un éventuel chemin donné :
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 sera
60, et non 10 !
Si vous voulez empêcher le partage de workers, classez vos
définitions de workers selon la longueur des URLs, de la plus
longue à la plus courte. Si au contraire vous voulez favoriser
ce partage, utilisez l'ordre de classement inverse. Voir aussi
l'avertissement à propos de l'ordre de classement des directives
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, fcgi,
ftp, http et scgi.
Les workers de répartition sont des workers virtuels qui utilisent les workers directs, connus comme faisant partie de leurs membres, pour le traitement effectif des requêtes. Chaque répartiteur peut comporter plusieurs membres. Lorsqu'il traite une requête, il choisit un de ses membres en fonction de l'algorithme de répartition de charge défini.
Un worker de répartition est créé si son URL de worker comporte
balancer comme indicateur de protocole. L'URL du
répartiteur permet d'identifier de manière unique le worker de
répartition. La directive
Vous pouvez restreindre l'accès à votre mandataire via le bloc
de contrôle
Pour plus de détails sur les directives de contrôle d'accès,
voir la documentation du module
Restreindre l'accès de manière stricte est essentiel si vous
mettez en oeuvre un mandataire direct (en définissant la directive
ProxyRequests Off), le contrôle
d'accès est moins critique car les clients ne peuvent contacter
que les serveurs que vous avez spécifiés.
Voir aussi la variable d'environnement Proxy-Chain-Auth.
Si vous utilisez la directive
Un serveur mandataire Apache httpd situé à l'intérieur d'un Intranet
doit faire suivre les requêtes destinées à un serveur externe à
travers le pare-feu de l'entreprise (pour ce faire, définissez la
directive
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
Pour les cas où
Il s'agit des variables force-proxy-request-1.0 et
proxy-nokeepalive.
Certaines méthodes de requêtes comme POST comportent un corps de
requête. Le protocole HTTP stipule que les requêtes qui comportent
un corps doivent soit utiliser un codage de transmission
fractionnée (chunked transfer encoding), soit envoyer un en-tête de requête
Content-Length. Lorsqu'il fait suivre ce genre de
requête vers le serveur demandé, 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.
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.
La directive
Lorsqu'il est configuré en mode mandataire inverse (en utilisant
par exemple la directive
X-Forwarded-ForX-Forwarded-HostHost.X-Forwarded-ServerCes en-têtes doivent être utilisés avec précautions sur le
serveur demandé, car ils contiendront plus d'une valeur (séparées
par des virgules) si la requête originale contenait déjà un de ces
en-têtes. Par exemple, vous pouvez utiliser
%{X-Forwarded-For}i dans la chaîne de format du journal
du serveur demandé pour enregistrer les adresses IP des clients
originaux, mais il est possible que vous obteniez plusieurs adresses
si la requête passe à travers plusieurs mandataires.
Voir aussi les directives
Note : Si vous devez ajouter des en-têtes particuliers à la
requête mandatée, utilisez la directive
Les directives situées dans une section
Par exemple, les lignes suivantes n'autoriseront à accéder à un
contenu via votre serveur mandataire que les hôtes appartenant à
votre-reseau.example.com :
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 :
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
Une URL d'arrière-plan sera concernée par le conteneur Proxy si
elle commence par la url-avec-jokers, même si le
dernier segment de chemin de la directive ne correspond qu'à un
préfixe de segment dee chemin de l'URL d'arrière-plan. Par exemple, <Proxy
http://example.com/foo> correspondra entre autres aux URLs
http://example.com/foo, http://example.com/foo/bar, et
http://example.com/foobar. La correspondance de l'URL finale
diffère du comportement de la section
Pour un contrôle plus fin de la correspondance des URL, voir la
directive
La directive
IsErrorIgnoreStartBodyLa directive
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
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
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.
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
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
Pour activer la fonctionnalité de mandataire sur les sites chiffrés en HTTPS, le module
N'activez pas la fonctionnalité de mandataire avec la directive
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 :
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.
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.
La directive
Cette directive permet de définir le nombre de membres pouvant être ajoutés au groupe de répartition de charge préconfiguré d'un serveur virtuel. Elle n'est active que si le groupe a été préconfiguré avec un membre au minimum.
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.
Cette directive permet à un serveur virtuel d'hériter des
directives
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
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
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
La directive
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
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
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 <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
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 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.
unix: tient compte de la directive
'|', la directive
[P,NE].Supposons que le serveur local a pour adresse
http://example.com/ ; alors la ligne
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.
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.
Le drapeau ! permet de soustraire un sous-répertoire
du mandat inverse, comme dans l'exemple suivant :
va mandater toutes les requêtes pour /miroir/foo
vers backend.example.com, sauf les requêtes
pour /miroir/foo/i.
Les directives
Pour les mêmes raisons, les exclusions doivent se situer
avant les directives
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 clé=valeur 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 permet
de réduire cette valeur par défaut. 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.
Le groupement de connexions est maintenu au niveau de chaque
processus enfant du serveur web, et max, 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ètres de BalancerMember |
|---|
| 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
| ||||||
| 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 SERVER_BUSY 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 mod_proxy à
fermer immédiatement une connexion vers le serveur
d'arrière-plan après utilisation, et ainsi désactiver le jeu de
connexions permanentes vers ce serveur. Ceci peut s'avérer utile
dans des situations où un pare-feu situé entre Apache httpd et le
serveur d'arrière-plan (quelque soit le protocole) interrompt
des connexions de manière silencieuse, ou lorsque le serveur
d'arrière-plan lui-même est accessible par rotation de DNS
(round-robin DNS). Pour désactiver la réutilisation du jeu de
connexions, définissez cette clé à On.
| ||||||
| enablereuse | On | Fournie à l'intention des gestionnaires de projet
qui nécessitent un accord pour la réutilisation des connexions
(tels que | ||||||
| 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 | ||||||
| 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.
Pour les valeurs négatives, le test est une simple vérification
de socket, alors que pour les valeurs positives, il s'agit d'une
vérification plus approfondie dépendant du protocole.
Avec AJP, CPING sur la connexion ajp13 (implémenté sur Tomcat
3.3.2+, 4.1.28+ et 5.0.13+). Avec HTTP,
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 | ||||||
| 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. |
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
| Paramètres du répartiteur |
|---|
| 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 | "." | Permet de définir le caractère de séparation dans le cookie de session. En effet, certains serveurs d'application d'arrière-plan n'utilisent pas le '.' comme caractère de séparation. Par exemple, le serveur Oracle Weblogic utilise le caractère '!'. Cette option permet donc de définir le caractère de séparation à une valeur appropriée. Si elle est définie à 'Off', aucun caractère de séparation ne sera 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 depuis la version 2.4.5 du serveur HTTP Apache. |
| nonce | <auto> | 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.
En 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. |
Exemple de configuration d'un répartiteur de charge
Configuration d'un serveur cible de réserve qui ne sera utilisé que si aucun autre serveur cible n'est disponible
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.
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.
Lorsque la directive ProxyPass est utilisée à l'intérieur d'une
section
Cette directive ne peut pas être placée dans une section
Si vous avez besoin d'un configuration de mandataire inverse plus
souple, reportez-vous à la documentaion de la directive [P].
Le mot-clé optionnel interpolate, en combinaison avec la directive
Cette directive est identique à la directive
Supposons que le serveur local a pour adresse
http://example.com/ ; alors
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.
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 :
Le drapeau ! vous permet de ne pas mandater un
sous-répertoire donné.
Dans une section
Si vous avez besoin d'une configuration du mandataire inverse
plus flexible, voyez la directive [P].
Lorsque le paramètre URL n'utilise pas de références arrières dans l'expression rationnelle, l'URL originale sera ajoutée au paramètre URL.
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.
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
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
Supposons par exemple que le serveur local a pour adresse
http://example.com/ ; alors
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
httpd 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
Notez que la directive RewriteRule ... [P]) du module
Le mot-clé optionnel interpolate,
utilisé en combinaison avec la directive
Lorsque cette directive est utilisée dans une section
Cette directive ne peut pas être placée dans une section
L'utilisation de cette directive est similaire à celle de la
directive Set-Cookie.
Cette directive s'avère utile en conjonction avec la directive
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
va réécrire un cookie possédant un chemin d'arrière-plan /
(ou /example ou en fait tout chemin)
en /mirror/foo/..
La directive
Chaque paramètre de la directive
*, 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 "*",
Dans le cas contraire, pour toute requête vers une ressource FTP
ou HTTP via le mandataire,
Notez que les recherches DNS peuvent ralentir le processus de démarrage du serveur.
Notez qu'example suffirait aussi pour atteindre
ces sites.
Hosts conviendrait aussi s'il était référencé par adresse IP.
Notez aussi que
bloque les connexions vers tous les sites.
La directive 512 ou définie à
0 pour indiquer que la taille de tampon par défaut du
système doit être utilisée.
La directive 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.
La directive Max-Forwards. Ceci permet de se prémunir
contre les boucles infinies de mandataires ou contre les attaques de
type déni de service.
Notez que la définition de la directive
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
Cette directive n'a d'utilité que pour les serveurs mandataires
Apache httpd au sein d'Intranets. La directive
Le type des arguments serveur de la directive
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 domaines sont toujours spécifiés en les préfixant par un point.
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.
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.0255.255.0.0)192.168.112.0/21192.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.
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.
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 adresses IP (ou souvent en une liste d'hôtes avec différentes adresses IP).
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.
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.
Cette directive n'a d'utilité que pour les serveurs mandataires
Apache httpd au sein d'un Intranet. La directive
Via pour les requêtes mandatéesCette 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:.
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.On, chaque requête ou réponse
se verra ajouter une ligne d'en-tête Via: pour le
serveur courant.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:.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é.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
Cette directive n'affecte pas le traitement des réponses informatives (1xx), de type succès normal (2xx), ou de redirection (3xx).
Cette directive, ainsi que l'argument interpolate des
directives ${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.
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
L'argument Full produit le même effet que l'argument On.
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.
Cette option n'est utile que dans le cas du mandat HTTP traité
par
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.