Serveur Apache HTTP Version 2.4
Description: | Module fournissant le support de FastCGI à
mod_proxy |
---|---|
Statut: | Extension |
Identificateur de Module: | proxy_fcgi_module |
Fichier Source: | mod_proxy_fcgi.c |
Compatibilité: | Disponible depuis la version 2.3 d'Apache |
Pour fonctionner, ce module nécessite le chargement de
mod_proxy
. Il fournit le support du protocole FastCGI.
Ainsi, pour pouvoir traiter le protocole FastCGI
,
mod_proxy
et mod_proxy_fcgi
doivent être chargés dans le serveur.
A la différence de mod_fcgid et mod_fastcgi,
mod_proxy_fcgi
n'est pas en mesure de démarrer le
processus de l'application ; fcgistarter
est
fourni à cet effet sur certaines plateformes. Le framework
applicatif FastCGI utilisé peut aussi fournir la gestion des
processus ou des lancements de programmes externes.
N'activez pas la fonctionnalité de mandataire avant d'avoir sécurisé votre serveur. Les serveurs mandataires ouverts sont dangereux non seulement pour votre réseau, mais aussi pour l'Internet au sens large.
Ce module ne fournit aucune directive.
Pour que ces exemples fonctionnent, vous ne devez pas oublier
d'activer mod_proxy
et
mod_proxy_fcgi
.
ProxyPass /mon_appli/ fcgi://localhost:4000/
mod_proxy_fcgi
interdisant par défaut la
réutilisation des connexions, lorsqu'une requête a été traitée, la
connexion ne sera pas maintenue ouverte par le processus enfant
httpd, et ne sera donc pas réutilisée. Cependant, si l'application
FastCGI supporte les connexions httpd simultanées, vous pouvez opter
pour la réutilisation des connexions comme dans l'exemple suivant :
ProxyPass /myapp/ fcgi://localhost:4000/ enablereuse=on
Dans l'exemple suivant, l'URI de la requête est transmis en tant que chemin du système de fichiers pour l'exécution du démon PHP-FPM. L'URL de la requête est implicitement ajoutée au second paramètre. PHP-FPM est à l'écoute de l'hôte et du port qui suivent fcgi://. La conservation des connexions est activée.
ProxyPassMatch ^/myapp/.*\.php(/.*)?$ fcgi://localhost:9000/var/www/ enablereuse=on
Dans l'exemple suivant, l'URI de la requête est transmis en tant que chemin du système de fichiers pour l'exécution du démon PHP-FPM. Dans ce cas cependant, PHP-FPM est à l'écoute d'un socket de domaine unix (UDS). Cette fonctionnalité est disponible à partir de la version 2.4.9. Avec cette syntaxe, si un nom d'hôte et un port sont ajoutés après fcgi://, ils seront ignorés.
# A ce jour, UDS ne supporte pas la réutilisation des connexions ProxyPassMatch ^/(.*\.php(/.*)?)$ "unix:/var/run/php5-fpm.sock|fcgi://localhost/var/www/"
La passerelle à répartition de charge nécessite le chargement du
module mod_proxy_balancer
et d'au moins un module
fournissant un algorithme de répartition de charge, comme
mod_lbmethod_byrequests
en plus des modules
déjà cités. mod_lbmethod_byrequests
est le module
par défaut et sera utilisé dans cet exemple de configuration.
ProxyPass /myapp/ balancer://myappcluster/ <Proxy balancer://myappcluster/> BalancerMember fcgi://localhost:4000 BalancerMember fcgi://localhost:4001 </Proxy>
Vous pouvez aussi forcer le traitement d'une requête en tant que requête de mandataire inverse en créant un court-circuiteur de gestionnaire approprié. Dans l'exemple ci-dessous, toutes les requêtes pour des scripts PHP seront transmises au serveur FastCGI spécifié par mandat inverse. Cette fonctionnalité est disponible à partir de la version 2.4.10 du serveur HTTP Apache. Pour des raisons de performances, il est recommandé de définir un worker (configuration d'un mandataire) représentant le même serveur fcgi:// d'arrière-plan. Avec cette configuration, il est possible d'effectuer une correspondance directe entre l'URI et le chemin du fichier sur le serveur, et le chemin local du fichier sera alors transmis au serveur d'arrière-plan. Lorsque FastCGI est configuré ainsi, le serveur est en mesure de calculer le PATH_INFO le plus approprié.
<FilesMatch \.php$> # Note : la seule partie variable est /path/to/app.sock SetHandler "proxy:unix:/path/to/app.sock|fcgi://localhost/" </FilesMatch> # Définition d'une configuration de mandataire qui convient. # La partie qui est mise en correspondance avec la valeur de # SetHandler est la partie qui suit le "pipe". Si vous devez faire # une distinction, "localhost" peut être changé en un nom de serveur # unique. <Proxy fcgi://localhost/ enablereuse=on max=10> </Proxy> <FilesMatch ...> SetHandler "proxy:fcgi://localhost:9000" </FilesMatch> <FilesMatch ...> SetHandler "proxy:balancer://myappcluster/" </FilesMatch>
En plus des directives de configuration qui contrôlent le
comportement de mod_proxy
, de nombreuses
variables d'environnement permettent de piloter le
fournisseur du protocole FCGI :
mod_proxy_fcgi
ne créera jamais
ni n'exportera la variable d'environnement PATH_INFO,
ce qui permet au serveur FCGI d'arrière-plan de déterminer
correctement SCRIPT_NAME et Script-URI, et
de se conformer à la section 3.3 de la RFC 3875. Si au contraire
vous avez souhaitez que mod_proxy_fcgi
génère une
"estimation la plus exacte possible" de PATH_INFO,
définissez la variable d'environnement
proxy-fcgi-pathinfo. Ceci peut servir de
contournement pour une bogue présente dans certaines
implémentations de FCGI. Cette variable peut être
multivaluée afin de pouvoir choisir la valeur la plus appropriée
(versions 2.4.11 et supérieures) :