<-
Apache > Serveur HTTP > Documentation > Version 2.5 > Modules

Module Apache mod_proxy_fcgi

Langues Disponibles:  en  |  fr 

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

Sommaire

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.

Avertissement

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.

Sujets

Directives

Traitement des bugs

Voir aussi

top

Exemples

Pour que ces exemples fonctionnent, vous ne devez pas oublier d'activer mod_proxy et mod_proxy_fcgi.

Instance d'application unique

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 :

Instance d'application unique, réutilisation des connexions (versions 2.4.11 et supérieures)

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.

PHP-FPM

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.

PHP-FPM with UDS

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.

Passerelle à répartition de charge vers plusieurs instances de l'application

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

Mandataire via un gestionnaire

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

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
Par défaut, 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) :
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.
top

Directive ProxyFCGIBackendType

Description:Specify the type of backend FastCGI application
Syntaxe:ProxyFCGIBackendType FPM|GENERIC
Défaut:ProxyFCGIBackendType FPM
Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
AllowOverride:FileInfo
Statut:Extension
Module:mod_proxy_fcgi
Compatibilité:Available in version 2.4.26 and later

This directive allows the type of backend FastCGI application to be specified. Some FastCGI servers, such as PHP-FPM, use historical quirks of environment variables to identify the type of proxy server being used. Set this directive to "GENERIC" if your non PHP-FPM application has trouble interpreting environment variables such as SCRIPT_FILENAME or PATH_TRANSLATED as set by the server.

One example of values that change based on the setting of this directive is SCRIPT_FILENAME. When using mod_proxy_fcgi historically, SCRIPT_FILENAME was prefixed with the string "proxy:fcgi://". This variable is what some generic FastCGI applications would read as their script input, but PHP-FPM would strip the prefix then remember it was talking to Apache. In 2.4.21 through 2.4.25, this prefix was automatically stripped by the server, breaking the ability of PHP-FPM to detect and interoperate with Apache in some scenarios.

top

Directive ProxyFCGISetEnvIf

Description:Allow variables sent to FastCGI servers to be fixed up
Syntaxe:ProxyFCGISetEnvIf conditional-expression [!]environment-variable-name [value-expression]
Contexte:configuration du serveur, serveur virtuel, répertoire, .htaccess
AllowOverride:FileInfo
Statut:Extension
Module:mod_proxy_fcgi
Compatibilité:Available in version 2.4.26 and later

Just before passing a request to the configured FastCGI server, the core of the web server sets a number of environment variables based on details of the current request. FastCGI programs often uses these environment variables as inputs that determine what underlying scripts they will process, or what output they directly produce.

Examples of noteworthy environment variables are:

This directive allows the environment variables above, or any others of interest, to be overridden. This directive is evaluated after the initial values for these variables are set, so they can be used as input into both the condition expressions and value expressions.

Parameter syntax:

conditional-expression
Specifies an expression that controls whether the environment variable that follows will be modified. For information on the expression syntax, see the examples that follow or the full specification at the ap_expr documentation.
environment-variable-name
Specifies the CGI environment variable to change, such as PATH_INFO. If preceded by an exclamation point, the variable will be unset.
value-expression
Specifies the replacement value for the preceding environment variable. Backreferences, such as "$1", can be included from regular expression captures in conditional-expression. If omitted, the variable is set (or overridden) to an empty string — but see the Note below.
# A basic, unconditional override
ProxyFCGISetEnvIf "true" PATH_INFO "/example"

# Use an environment variable in the value
ProxyFCGISetEnvIf "true" PATH_INFO "%{reqenv:SCRIPT_NAME}"

# Use captures in the conditions and backreferences in the replacement
ProxyFCGISetEnvIf "reqenv('PATH_TRANSLATED') =~ m|(/.*prefix)(\d+)(.*)|" PATH_TRANSLATED "$1$3"

Note: Unset vs. Empty

The following will unset VARIABLE, preventing it from being sent to the FastCGI server:
ProxyFCGISetEnvIf true !VARIABLE
Whereas the following will erase any existing value of VARIABLE (by setting it to the empty string), but the empty VARIABLE will still be sent to the server:
ProxyFCGISetEnvIf true VARIABLE
The CGI/1.1 specification does not distinguish between a variable with an empty value and a variable that does not exist. However, many CGI and FastCGI implementations distinguish (or allow scripts to distinguish) between the two. The choice of which to use is dependent upon your implementation and your reason for modifying the variable.

Langues Disponibles:  en  |  fr 

top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.