mod_proxy_scgi - Serveur HTTP Apache Version 2.4

Serveur HTTP Apache Version 2.4

Apache > Serveur HTTP > Documentation > Version 2.4 > Modules

# Module Apache mod_proxy_scgi

Langues Disponibles: en | fr

Cette traduction peut être périmée. Vérifiez la version anglaise pour les changements récents.

Description: | Module fournissant le support de la passerelle SCGI à `mod_proxy`
Statut: | Extension
Identificateur de Module: | proxy_scgi_module
Fichier Source: | mod_proxy_scgi.c
Compatibilité: | Disponible depuis la version 2.2.14 d'Apache

### Sommaire

Pour pouvoir fonctionner, ce module requiert le chargement de `mod_proxy`. Il fournit le support du protocole SCGI, version 1.

Ainsi, pour être en mesure de traiter le protocole SCGI, `mod_proxy` et `mod_proxy_scgi` doivent être chargés dans le serveur.

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

- Exemples
- Variables d'environnement

### Directives

### Traitement des bugs

- Journal des modifications de httpd
- Problèmes connus
- Signaler un bug

### Voir aussi

- `mod_proxy`
- `mod_proxy_balancer`
- Commentaires

## Exemples

Rappelez-vous, pour que les exemples suivants puissent fonctionner, vous devez activer `mod_proxy` et `mod_proxy_scgi`.

### Passerelle simple

    ProxyPass "/scgi-bin/" "scgi://localhost:4000/"

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

    ProxyPass "/scgi-bin/" "balancer://somecluster/"
    <Proxy "balancer://somecluster">
        BalancerMember "scgi://localhost:4000"
        BalancerMember "scgi://localhost:4001"
    </Proxy>

## Variables d'environnement

En plus des directives de configuration qui permettent de contrôler le comportement de `mod_proxy`, une variable d'environnement peut aussi contrôler le fournisseur de protocole SCGI :

proxy-scgi-pathinfo
  Par défaut, `mod_proxy_scgi` ne créera ni exportera jamais la variable d'environnement PATH_INFO. Ceci permet au serveur SCGI d'arrière-plan de déterminer correctement SCRIPT_NAME et Script-URI, et de rester en conformité avec la section 3.3 de la RFC 3875. Si au contraire vous souhaitez que `mod_proxy_scgi` génère une estimation la plus précise possible de PATH_INFO, définissez cette variable d'environnement. La variable doit être définie avant que la directive `SetEnv` ne soit effective. Il est possible d'utiliser à la place la directive `SetEnvIf` : `SetEnvIf Request_URI . proxy-scgi-pathinfo`

## Directive ProxySCGIInternalRedirect

Description: | Active ou désactive les réponses de redirection interne en provenance du serveur cible.
Syntaxe: | `ProxySCGIInternalRedirect On|Off|Headername`
Défaut: | `ProxySCGIInternalRedirect On`
Contexte: | configuration globale, serveur virtuel, répertoire
Statut: | Extension
Module: | mod_proxy_scgi
Compatibilité: | Le paramètre Headername est disponible depuis la version 2.4.13 du serveur HTTP Apache.

La directive `ProxySCGIInternalRedirect` permet au serveur cible de rediriger en interne la passerelle vers une URL différente. Cette fonctionnalité trouve son origine dans `mod_cgi` qui redirige la réponse en interne si l'état de la réponse est `OK` (`200`), et si la réponse contient un en-tête `Location` (ou un autre en-tête défini) dont la valeur débute par un slash (`/`). Cette valeur est interprétée comme une nouvelle URL locale vers laquelle Apache httpd effectue sa redirection.

De ce point de vue, `mod_proxy_scgi` fait la même chose que `mod_cgi`, mais vous pouvez en plus désactiver la fonctionnalité ou spécifier l'utilisation d'un en-tête autre que `Location`.

### Exemple

        ProxySCGIInternalRedirect Off
    # Django et certains autres frameworks qualifient pleinement les "URLs
    # locales" définies par l'application ; il faut donc utiliser un autre
    # en-tête.
    <Location /django-app/>
        ProxySCGIInternalRedirect X-Location
    </Location>

## Directive ProxySCGISendfile

Description: | Active l'évaluation du pseudo en-tête de réponse X-Sendfile
Syntaxe: | `ProxySCGISendfile On|Off|nom-en-tête`
Défaut: | `ProxySCGISendfile Off`
Contexte: | configuration globale, serveur virtuel, répertoire
Statut: | Extension
Module: | mod_proxy_scgi

La directive `ProxySCGISendfile` permet au serveur cible SCGI de faire servir les fichiers directement par la passerelle. Ceci s'avère bénéfique en matière de performances — httpd peut alors utiliser `sendfile` ou d'autres optimisations, ce qui n'est pas possible si les fichiers passent par la socket du serveur cible. En outre, les fichiers ne sont transmis qu'une seule fois.

L'argument de la directive `ProxySCGISendfile` détermine le comportement de la passerelle :

`Off`
  Aucun traitement particulier n'est effectué.
`On`
  La passerelle recherche un en-tête dans la réponse du serveur cible nommé `X-Sendfile`, et interprète sa valeur comme le nom du fichier à servir. L'en-tête est ensuite supprimé de la réponse finale. Cet argument produit le même effet que `ProxySCGISendfile X-Sendfile`.
toute autre valeur
  Identique à `On`, mais au lieu de rechercher le nom d'en-tête codé en dur `X-Sendfile`, c'est la valeur de l'argument qui constitue le nom de l'en-tête à rechercher.

### Exemple

        # Utilise le nom d'en-tête par défaut (X-Sendfile)
        ProxySCGISendfile On

        # Utilise un nom d'en-tête différent
        ProxySCGISendfile X-Send-Static

Langues Disponibles: en | fr