Module Apache mod_proxy_fcgi

Exemples ¶

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/réutilisation 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.

ProxyPassMatch "^/(.*\.php(/.*)?)$" "unix:/var/run/php5-fpm.sock|fcgi://localhost/var/www/"

Dans l'exemple suivant, on force le module à traiter les paquets de données en provenance du serveur FCGI d'arrière-plan dès leur réception, sans les faire transiter par un tampon.

ProxyPassMatch "^/myapp/.*\.php(/.*)?$" "fcgi://localhost:9000/var/www/" enablereuse=on flushpackets=on

L'exemple suivant est similaire au précédent avec une différence : ici, les données en provenance du serveur FCGI d'arrière-plan sont traitées après un temps de valeur fixe (elles sont mises en tampon). Cette méthode est utile si le serveur FCGI d'arrière-plan envoie ses données sous forme de petits paquets, auquel cas le traitement immédiat de chacun d'entre eux serait inefficace et couteux en ressources. Notez que cet exemple ne sera peut-être pas adapté dans le cas où l'envoi de paquets de données par l'application FCGI est bloqué par l'attente de données en provenance du client.

ProxyPassMatch "^/myapp/.*\.php(/.*)?$" "fcgi://localhost:9000/var/www/" flushpackets=on flushwait=20

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>

Variables d'environnement ¶

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 :

proxy-fcgi-pathinfo

Lorsqu'il est configuré via les directives ProxyPass ou ProxyPassMatch, mod_proxy_fcgi ne définit pas 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) :

first-dot

PATH_INFO est extrait à partir du slash qui suit le premier "." de l'URL.

last-dot

PATH_INFO est extrait à partir du slash qui suit le dernier "." de l'URL.

full

PATH_INFO est calculé en supposant que l'URL correspond au chemin du système de fichiers.

unescape

PATH_INFO correspond à la partie chemin de l'URL avec ses séquences d'échappement décodées.

toute autre valeur

PATH_INFO correspond à la partie chemin de l'URL. Auparavant, c'était la seule option pour proxy-fcgi-pathinfo.