Serveur Apache HTTP Version 2.5
Serveur Apache HTTP Version 2.5
Deux types de variables d'environnement affectent le serveur HTTP Apache.
Le premier type correspond aux variables d'environnement contrôlées par le système d'exploitation sous-jacent et définies avant le démarrage du serveur. Leurs valeurs peuvent être utilisées directement dans les fichiers de configuration, et peuvent éventuellement être transmises aux scripts CGI et SSI via la directive PassEnv.
Le second type correspond aux variables nommées appelées aussi variables d'environnement dans lesquelles le serveur HTTP Apache stocke des informations via un mécanisme spécial. Ces informations peuvent servir à contrôler diverses opérations comme l'enregistrement des traces ou le contrôle d'accès. On utilise aussi ces variables dans le mécanisme de communication avec les programmes externes comme les scripts CGI. Ce document présente différentes méthodes pour manipuler et utiliser ces variables.
Bien que ces variables soient référencées comme variables d'environnement, il ne faut pas les confondre avec les variables d'environnement contrôlées par le système d'exploitation sous-jacent. En fait, ces variables sont stockées et manipulées dans une structure interne à Apache. Elles ne deviennent de véritables variables d'environnement du système d'exploitation que lorsqu'elles sont mises à la disposition de scripts CGI et de scripts inclus côté serveur (SSI). Si vous souhaitez manipuler l'environnement du système d'exploitation sous lequel le serveur s'exécute, vous devez utiliser les mécanismes standards de manipulation de l'environnement fournis par l'interpréteur de commandes (shell) de votre système d'exploitation.
| Modules Apparentés | Directives Apparentées |
|---|---|
La méthode la plus élémentaire pour définir une variable
d'environnement au niveau d'Apache consiste à utiliser la directive
inconditionnelle SetEnv. Les variables peuvent aussi être transmises depuis
l'environnement du shell à partir duquel le serveur a été démarré en
utilisant la directive
PassEnv.
Pour plus de souplesse, les directives fournies par le module
mod_setenvif permettent de définir les
variables d'environnement en tenant compte des caractéristiques
de chaque requête. Par exemple, une
variable pourrait n'être définie que lorsqu'un navigateur spécifique
(User-Agent) a généré la requête, ou seulement quand un en-tête
Referer particulier est présent. La directive
RewriteRule du module
mod_rewrite qui utilise l'option
[E=...] pour définir
les variables d'environnement apporte encore plus de souplesse.
Finalement, le module mod_unique_id définit la variable
d'environnement UNIQUE_ID pour chaque requête à une valeur
qui est garantie unique parmi "toutes" les requêtes sous des
conditions très spécifiques.
En plus de l'ensemble des variables d'environnement internes à la configuration d'Apache et de celles transmises depuis le shell, les scripts CGI et les pages SSI se voient affectés un ensemble de variables d'environnement contenant des méta-informations à propos de la requête comme préconisé dans la spécification sur les CGIs.
suexec pour exécuter des
scripts CGI, l'environnement est nettoyé et réduit à un ensemble de
variables sûres avant l'exécution du script. La liste des
variables sûres est définie à la compilation dans
suexec.c.SetEnv s'exécute assez tard au
cours du traitement de la requête, ce qui signifie que des
directives telles que SetEnvIf et RewriteCond ne verront pas
les variables qu'elle aura définies.| Modules Apparentés | Directives Apparentées |
|---|---|
La communication d'informations aux scripts CGI constitue une des principales utilisations des variables d'environnement. Comme indiqué plus haut, l'environnement transmis aux scripts CGI comprend des méta-informations standards à propos de la requête, en plus des variables définies dans la configuration d'Apache. Pour plus de détails, se référer au tutoriel CGI.
Les documents inclus côté serveur (SSI) traités par le filtre
INCLUDES du module mod_include,
peuvent afficher les
variables d'environnement à l'aide de l'élément echo,
et peuvent utiliser des variables d'environnement dans les éléments
de contrôle de flux pour rendre certaines parties d'une page
conditionnelles en fonction des caractéristiques de la requête.
Apache fournit aussi les variables d'environnement CGI standards
aux pages SSI
comme indiqué plus haut. Pour plus de détails, se référer au
tutoriel SSI.
L'accès au serveur peut être contrôlé en fonction de la valeur de
variables d'environnement à l'aide des directives
allow from env= et deny from env=.
En association avec la directive
SetEnvIf, ceci confère une
grande souplesse au contrôle d'accès au serveur en fonction des
caractéristiques du client. Par exemple, vous pouvez utiliser ces
directives pour interdire l'accès depuis un navigateur particulier
(User-Agent).
Les variables d'environnement peuvent être enregistrées dans le
fichier de log des accès à l'aide de l'option %e de la
directive LogFormat.
En outre, la décision de tracer ou non les requêtes peut être prise
en fonction de l'état de variables d'environnement en utilisant la
forme conditionnelle de la directive
CustomLog. En
association avec la directive SetEnvIf, ceci confère une grande souplesse au contrôle
du traçage des requêtes. Par exemple, vous pouvez choisir de ne pas
tracer les requêtes pour des noms de fichiers se terminant par
gif, ou encore de ne tracer que les requêtes des clients
n'appartenant pas à votre sous-réseau.
La directive Header
peut se baser sur la présence ou l'absence d'une variable
d'environnement pour décider si un certain en-tête HTTP sera placé
dans la réponse au client. Ceci permet, par exemple, de n'envoyer un
certain en-tête de réponse que si un en-tête correspondant est présent
dans la requête du client.
Les filtres externes configurés par le module
mod_ext_filter à l'aide de la directive ExtFilterDefine peuvent être
activés de manière conditionnelle en fonction d'une variable
d'environnement à l'aide des options
disableenv= et enableenv=.
La forme %{ENV:variable} de
TestString dans la
directive RewriteCond
permet au moteur de réécriture du module
mod_rewrite de prendre des
décisions conditionnées par des variables d'environnement.
Notez que les variables accessibles dans
mod_rewrite sans le préfixe
ENV: ne sont pas de véritables variables
d'environnement. Ce sont plutôt des variables spécifiques à
mod_rewrite
qui ne sont pas accessibles pour les autres modules.
Des problèmes d'interopérabilité ont conduit à l'introduction de
mécanismes permettant de modifier le comportement d'Apache lorsqu'il
dialogue avec certains clients. Afin de rendre ces mécanismes aussi
souples que possible, ils sont invoqués en définissant des variables
d'environnement, en général à l'aide de la directive
BrowserMatch, bien que les
directives SetEnv et
PassEnv puissent aussi être
utilisées, par exemple.
Ceci force le traitement d'une requête comme une requête HTTP/1.0 même si elle a été rédigée dans un langage plus récent.
Si le filtre DEFLATE est activé, cette variable
d'environnement ignorera les réglages accept-encoding de votre
navigateur et enverra une sortie compressée inconditionnellement.
Cette variable entraîne la suppression de tout champ
Vary des en-têtes de la réponse avant que cette dernière
soit renvoyée au client. Certains clients n'interprètent pas ce champ
correctement, et la définition de cette variable permet de contourner
ce problème, mais implique aussi la définition de
force-response-1.0.
Cette variable force une réponse en langage HTTP/1.0 aux clients qui envoient des requêtes dans le même langage. Elle fut implémentée à l'origine suite à des problèmes avec les mandataires d'AOL. Certains clients en langage HTTP/1.0 ne réagissent pas correctement face à une réponse en langage HTTP/1.1, et cette variable peut être utilisée pour assurer l'interopérabilité avec eux.
Positionnée à "1", cette variable désactive le filtre en sortie
DEFLATE fourni par le module mod_deflate pour les
types de contenu autres que text/html. Si vous préférez
utiliser des fichiers compressés statiquement,
mod_negotiation évalue aussi la variable (non
seulement pour gzip, mais aussi pour tous les encodages autres que
"identity").
Quand cette variable est définie, le filtre DEFLATE du
module mod_deflate est désactivé, et
mod_negotiation refusera de délivrer des ressources
encodées.
Disponible dans les versions 2.2.12 et ultérieures d'Apache
Lorsque cette variable est définie,
mod_cache ne sauvegardera pas de réponse
susceptible d'être mise en cache. Cette variable d'environnement
n'a aucune incidence sur le fait qu'une réponse déjà enregistrée
dans la cache soit utilisée ou non pour la requête courante.
Quand cette variable est définie, la directive
KeepAlive est désactivée.
Cette variable modifie le comportement du module
mod_negotiation. Si elle contient un symbole de
langage (tel que en, ja
ou x-klingon), mod_negotiation essaie de
délivrer une variante dans ce langage. S'il n'existe pas de telle
variante, le processus normal de
négociation s'applique.
Cette variable force le serveur à être plus prudent lors de l'envoi d'une redirection au client. Elle est en général utilisée quand un client présente un problème connu avec les redirections. Elle fut implémentée à l'origine suite a un problème rencontré avec le logiciel WebFolders de Microsoft qui ne gère pas correctement les redirections vers des ressources de type répertoire via des méthodes DAV.
Disponible dans les versions postérieures à 2.0.54
Quand Apache génère une redirection en réponse à une requête client, la réponse inclut un texte destiné à être affiché au cas où le client ne suivrait pas, ou ne pourrait pas suivre automatiquement la redirection. Habituellement, Apache marque ce texte en accord avec le jeu de caractères qu'il utilise, à savoir ISO-8859-1.
Cependant, si la redirection fait référence à une page qui utilise un jeu de caractères différent, certaines versions de navigateurs obsolètes essaieront d'utiliser le jeu de caractères du texte de la redirection plutôt que celui de la page réelle. Ceci peut entraîner, par exemple, un rendu incorrect du Grec.
Si cette variable d'environnement est définie, Apache omettra le jeu de caractères pour le texte de la redirection, et les navigateurs obsolètes précités utiliseront correctement celui de la page de destination.
L'envoi de pages d'erreur sans spécifier un jeu de caractères peut conduire à des attaques de type "cross-site-scripting" pour les navigateurs qui ne respectent pas la spécification HTTP/1.1 (MSIE) et tentent de déduire le jeu de caractères à partir du contenu. De tels navigateurs peuvent être facilement trompés et utiliser le jeu de caractères UTF-7 ; les contenus des données en entrée de type UTF-7 (comme les URI de requête) ne seront alors plus protégés par les mécanismes d'échappement usuels conçus pour prévenir les attaques de type "cross-site-scripting".
Ces directives modifient le comportement protocolaire du module
mod_proxy. Voir la documentation sur
mod_proxy et mod_proxy_http pour plus de détails.
Avec la version 2.4, Apache est plus strict avec la conversion
des en-têtes HTTP en variables d'environnement dans
mod_cgi et d'autres modules : dans les versions
précédentes, tout caractère invalide dans les noms d'en-têtes
était tout simplement remplacé par un caractère '_', ce qui
pouvait exposer à des attaques de type cross-site-scripting via
injection d'en-têtes (voir Bogues
du Web inhabituelles, planche 19/20).
Si vous devez supporter un client qui envoie des en-têtes non
conformes et si ceux-ci ne peuvent pas être corrigés, il existe
une solution de contournement simple mettant en jeu les modules
mod_setenvif et mod_header,
et permettant de prendre en compte ces en-têtes :
# L'exemple suivant montre comment prendre en compte un en-tête
# Accept_Encoding non conforme envoyé par un client. # SetEnvIfNoCase ^Accept.Encoding$ ^(.*)$ fix_accept_encoding=$1 RequestHeader set Accept-Encoding %{fix_accept_encoding}e env=fix_accept_encoding
Les versions antérieures recommandaient l'ajout de ces lignes dans httpd.conf pour tenir compte de problèmes connus avec certains clients. Comme les clients concernés sont maintenant très peu utilisés, cet ajout n'est pratiquement plus nécessaire.
# # The following directives modify normal HTTP response behavior. # The first directive disables keepalive for Netscape 2.x and browsers that # spoof it. There are known problems with these browser implementations. # The second directive is for Microsoft Internet Explorer 4.0b2 # which has a broken HTTP/1.1 implementation and does not properly # support keepalive when it is used on 301 or 302 (redirect) responses. # BrowserMatch "Mozilla/2" nokeepalive BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0 # # The following directive disables HTTP/1.1 responses to browsers which # are in violation of the HTTP/1.0 spec by not being able to grok a # basic 1.1 response. # BrowserMatch "RealPlayer 4\.0" force-response-1.0 BrowserMatch "Java/1\.0" force-response-1.0 BrowserMatch "JDK/1\.0" force-response-1.0
Dans cet exemple, les requêtes pour des images n'apparaissent pas dans le fichier de trace des accès. Il peut être facilement adapté pour empêcher le traçage de répertoires particuliers, ou de requêtes en provenance de certains hôtes.
SetEnvIf Request_URI \.gif image-request
SetEnvIf Request_URI \.jpg image-request
SetEnvIf Request_URI \.png image-request
CustomLog logs/access_log common env=!image-request
Cet exemple montre comment empêcher les utilisateurs ne faisant pas
partie de votre serveur d'utiliser des images de votre serveur comme
images en ligne dans leurs pages. Cette configuration n'est pas
recommandée, mais elle peut fonctionner dans des circonstances bien
définies. Nous supposons que toutes vos images sont enregistrées dans
un répertoire nommé /web/images.
SetEnvIf Referer "^http://www\.example\.com/" local_referal
# Autorise les navigateurs qui n'envoient aucune information de Referer
SetEnvIf Referer "^$" local_referal
<Directory /web/images>
Order Deny,Allow
Deny from all
Allow from env=local_referal
</Directory>
Pour plus d'informations sur cette technique, voir le tutoriel sur ServerWatch "Keeping Your Images from Adorning Other Sites".