mod_proxy_fcgi - Serveur Apache HTTP

Serveur Apache HTTP Version 2.4

Apache > Serveur HTTP > Documentation > Version 2.4 > 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.

### Directives

Ce module ne fournit aucune directive.

### Sujets

- Exemples
- Variables d'environnement

### Voir aussi

- `fcgistarter`
- `mod_proxy`

- Commentaires

## 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/

Cette application doit être en mesure de gérer plusieurs connexions simultanées. Par défaut, `mod_proxy` permet la réutilisation des connexions, si bien que lorsque le traitement d'une requête est terminé, le processus enfant httpd garde la connexion ouverte, et cette dernière ne sera pas réutilisée avant que le même processus httpd ne redirige une autre requête vers l'application. Si l'application FastCGI n'est pas en mesure de gérer un nombre suffisant de connexions simultanées avec httpd, les requêtes peuvent être bloquées jusqu'à ce que l'application ferme une connexion existante. Pour remédier à ce problème, on peut désactiver la réutilisation des connexions à l'aide de la directive `ProxyPass`, comme indiqué dans l'exemple suivant :

### Instance d'application unique, pas de réutilisation des connexions

          ProxyPass /mon_appli/ fcgi://localhost:4000/ disablereuse=on

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>

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

Langues Disponibles: en | fr

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