Serveur Apache HTTP Version 2.3
-
Serveur Apache HTTP Version 2.3
-
Le serveur HTTP Apache propose un mécanisme de stockage d'informations - dans des variables appelées variables d'environnement. 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.
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.
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
- # Allow browsers that do not send Referer info
- 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".
- -Serveur Apache HTTP Version 2.3
+Le serveur HTTP Apache propose un mécanisme de stockage d'informations + dans des variables appelées variables d'environnement. 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.
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.
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
+ # Allow browsers that do not send Referer info
+ 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".
+ +Serveur Apache HTTP Version 2.3
-
Ce document n'est pas une FAQ traditionnelle, mais plutôt un - guide sommaire vous indiquant ce qu'il faut faire lorsque vous - rencontrez des problèmes avec le serveur HTTP Apache.
- -La FAQ Apache 1.3 - constitue un document plus traditionnel, quoique légèrement - obsolète.
-
Si vous rencontrez des problèmes avec le serveur Apache, vous - devez effectuer les actions suivantes :
- -Apache essaie de vous aider à résoudre les problèmes
- rencontrés. Dans de nombreux cas, il fournira certains détails en
- enregistrant un ou plusieurs messages dans le journal des erreurs
- du serveur. Cela vous suffit parfois pour diagnostiquer et
- résoudre le problème vous-même (en corrigeant les permissions sur
- certains fichiers par exemple). La localisation du
- journal des erreurs de votre serveur est définie dans votre
- fichier de configuration par la directive ErrorLog, et sa valeur par défaut est
- /usr/local/apache2/logs/error_log.
Si vous avez fini par poster un message dans un des forums de - support, c'est probablement le premier endroit dans lequel on vous - demandera de rechercher des informations. S'il vous plait, - assurez-vous de savoir où trouver votre journal des erreurs. Si - vous n'en êtes pas sûr, cette page du - wiki peut vous orienter dans vos recherches.
Apache possède une communauté active d'utilisateurs prêts à - partager leurs connaissances. Prendre part à cette communauté est - en général le moyen le plus rapide et le plus efficace pour - obtenir des réponses à vos questions ou problèmes.
- -Liste de - diffusion des utilisateurs
- -Les utilisateurs peuvent aussi soumettre leurs problèmes à #apache sur Freenode IRC.
-Si vous avez suivi toutes ces étapes sans trouver la - solution à votre problème, merci de le signaler aux - développeurs de httpd en enregistrant un - rapport de bogue.
- -Si votre problème provoque un crash du serveur et génère un - vidage mémoire (core dump), merci de joindre ce - dernier (dans la mesure du possible).
-Avec des millions d'utilisateurs et moins de soixante - développeurs bénévoles, nous ne sommes pas en mesure de proposer - un support personnalisé pour Apache. Pour un support gratuit, nous - vous suggérons de participer à un forum utilisateur (voir plus - haut).
- -De nombreuses sociétés proposent un support Apache - professionnel et commercial.
-Serveur Apache HTTP Version 2.3
+Ce document n'est pas une FAQ traditionnelle, mais plutôt un + guide sommaire vous indiquant ce qu'il faut faire lorsque vous + rencontrez des problèmes avec le serveur HTTP Apache.
+ +La FAQ Apache 1.3 + constitue un document plus traditionnel, quoique légèrement + obsolète.
+Si vous rencontrez des problèmes avec le serveur Apache, vous + devez effectuer les actions suivantes :
+ +Apache essaie de vous aider à résoudre les problèmes
+ rencontrés. Dans de nombreux cas, il fournira certains détails en
+ enregistrant un ou plusieurs messages dans le journal des erreurs
+ du serveur. Cela vous suffit parfois pour diagnostiquer et
+ résoudre le problème vous-même (en corrigeant les permissions sur
+ certains fichiers par exemple). La localisation du
+ journal des erreurs de votre serveur est définie dans votre
+ fichier de configuration par la directive ErrorLog, et sa valeur par défaut est
+ /usr/local/apache2/logs/error_log.
Si vous avez fini par poster un message dans un des forums de + support, c'est probablement le premier endroit dans lequel on vous + demandera de rechercher des informations. S'il vous plait, + assurez-vous de savoir où trouver votre journal des erreurs. Si + vous n'en êtes pas sûr, cette page du + wiki peut vous orienter dans vos recherches.
Apache possède une communauté active d'utilisateurs prêts à + partager leurs connaissances. Prendre part à cette communauté est + en général le moyen le plus rapide et le plus efficace pour + obtenir des réponses à vos questions ou problèmes.
+ +Liste de + diffusion des utilisateurs
+ +Les utilisateurs peuvent aussi soumettre leurs problèmes à #apache sur Freenode IRC.
+Si vous avez suivi toutes ces étapes sans trouver la + solution à votre problème, merci de le signaler aux + développeurs de httpd en enregistrant un + rapport de bogue.
+ +Si votre problème provoque un crash du serveur et génère un + vidage mémoire (core dump), merci de joindre ce + dernier (dans la mesure du possible).
+Avec des millions d'utilisateurs et moins de soixante + développeurs bénévoles, nous ne sommes pas en mesure de proposer + un support personnalisé pour Apache. Pour un support gratuit, nous + vous suggérons de participer à un forum utilisateur (voir plus + haut).
+ +De nombreuses sociétés proposent un support Apache + professionnel et commercial.
+Serveur Apache HTTP Version 2.3
-L'authentification est un processus qui vous permet de vérifier - qu'une personne est bien celle qu'elle prétend être. L'autorisation - est un processus qui permet à une personne d'aller là où elle veut - aller, ou d'obtenir les informations qu'elle désire.
-
Modules et directives concernés Introduction Les prérequis Mise en oeuvre Autorisation d'accès à
-plusieurs personnes Problèmes possibles Autre méthode de stockage des mots de
-passe Utilisation de plusieurs fournisseurs
-d'authentification Pour aller plus loin qu'une simple
-autorisation Pour aller plus loin . . .Trois groupes de modules sont concernés par le processus -d'authentification et d'autorisation. Vous devrez utiliser au moins un -module de chaque groupe.
- -AuthType)
-
- AuthBasicProvider et AuthDigestProvider)
-
-
- Require)
-
- On peut aussi ajouter mod_authn_core et
- mod_authz_core. Ces modules implémentent des
- directives générales qui opèrent au dessus de tous les modules
- d'authentification.
Le module mod_authnz_ldap est un fournisseur
- d'authentification et d'autorisation. Le module
- mod_authz_host fournit une autorisation et un
- contrôle d'accès basés sur le nom du serveur, l'adresse IP ou
- certaines caractéristiques de la requête, mais ne fait pas partie du
- système fournisseur d'authentification. Le module
- mod_access_compat a été créé à des fins de
- compatibilité ascendante avec mod_access.
Vous devriez aussi jeter un coup d'oeil au manuel de recettes de Contrôle d'accès, qui décrit les différentes - méthodes de contrôle d'accès à votre serveur.
- -Si votre site web contient des informations sensibles ou - destinées seulement à un groupe de personnes restreint, les - techniques exposées dans cet article vont vous aider à vous assurer - que les personnes qui ont accès à ces pages sont bien celles - auxquelles vous avez donné l'autorisation d'accès.
- -Cet article décrit les méthodes "standards" de protection de - parties de votre site web que la plupart d'entre vous sont appelés à - utiliser.
- -Si vos données ont un réel besoin de sécurisation, prévoyez
- l'utilisation de mod_ssl en plus de toute méthode
- d'authentification.
Les directives décrites dans cet article devront être insérées
- soit au niveau de la configuration de votre serveur principal (en
- général dans une section <Directory>), soit au niveau de la
- configuration des répertoires (fichiers .htaccess)
Si vous envisagez l'utilisation de fichiers
- .htaccess, la configuration de votre serveur devra
- permettre l'ajout de directives d'authentification dans ces
- fichiers. Pour ce faire, on utilise la directive AllowOverride, qui spécifie quelles
- directives pourront éventuellement contenir les fichiers de
- configuration de niveau répertoire.
Comme il est ici question d'authentification, vous aurez besoin
- d'une directive AllowOverride
- du style :
- AllowOverride AuthConfig
-
Si vous avez l'intention d'ajouter les directives directement - dans le fichier de configuration principal, vous devrez bien entendu - posséder les droits en écriture sur ce fichier.
- -Vous devrez aussi connaître un tant soit peu la structure des - répertoires de votre serveur, ne serait-ce que pour savoir où se - trouvent certains fichiers. Cela ne devrait pas présenter de grandes - difficultés, et nous essaierons de clarifier tout ça lorsque le besoin - s'en fera sentir.
- -Enfin, vous devrez vous assurer que les modules
- mod_authn_core et mod_authz_core
- ont été soit compilés avec le binaire httpd, soit chargés par le
- fichier de configuration httpd.conf. Ces deux modules fournissent
- des directives générales et des fonctionnalités qui sont critiques
- quant à la configuration et l'utilisation de l'authentification et
- de l'autorisation au sein du serveur web.
Nous décrivons ici les bases de la protection par mot de passe - d'un répertoire de votre serveur.
- -Vous devez en premier lieu créer un fichier de mots de passe. La - méthode exacte selon laquelle vous allez créer ce fichier va varier - en fonction du fournisseur d'authentification choisi. Mais nous - entrerons dans les détails plus loin, et pour le moment, nous nous - contenterons d'un fichier de mots de passe en mode texte.
- -Ce fichier doit être enregistré à un endroit non accessible
- depuis le web, de façon à ce que les clients ne puissent pas le
- télécharger. Par exemple, si vos documents sont servis à partir de
- /usr/local/apache/htdocs, vous pouvez enregistrer le
- fichier des mots de passe dans
- /usr/local/apache/passwd.
L'utilitaire htpasswd fourni avec Apache
- permet de créer ce fichier. Vous le trouverez dans le répertoire
- bin de votre installation d'Apache. Si vous avez
- installé Apache à partir d'un paquetage tiers, il sera probablement
- dans le chemin par défaut de vos exécutables.
Pour créer le fichier, tapez :
- -
- htpasswd -c /usr/local/apache/passwd/passwords rbowen
-
htpasswd vous demandera d'entrer le mot de
- passe, et de le retaper pour confirmation :
- # htpasswd -c /usr/local/apache/passwd/passwords rbowen
- New password: mot-de-passe
- Re-type new password: mot-de-passe
- Adding password for user rbowen
-
Si htpasswd n'est pas dans le chemin par
- défaut de vos exécutables, vous devrez bien entendu entrer le chemin
- complet du fichier. Dans le cas d'une installation par défaut, il se
- trouve à /usr/local/apache2/bin/htpasswd.
Ensuite, vous allez devoir configurer le serveur de façon à ce
- qu'il demande un mot de passe et lui préciser quels utilisateurs ont
- l'autorisation d'accès. Pour ce faire, vous pouvez soit éditer le
- fichier httpd.conf, soit utiliser un fichier
- .htaccess. Par exemple, si vous voulez protéger le
- répertoire /usr/local/apache/htdocs/secret, vous pouvez
- utiliser les directives suivantes, soit dans le fichier
- /usr/local/apache/htdocs/secret/.htaccess, soit dans le
- fichier httpd.conf à l'intérieur d'une section <Directory
- /usr/local/apache/htdocs/secret> :
- AuthType Basic
- AuthName "Fichiers réservés"
- # (La ligne suivante est facultative)
- AuthBasicProvider file
- AuthUserFile /usr/local/apache/passwd/passwords
- Require user rbowen
-
Examinons ces directives une à une. La directive AuthType définit la méthode
- utilisée pour authentifier l'utilisateur. La méthode la plus
- courante est Basic, et elle est implémentée par
- mod_auth_basic. Il faut cependant garder à l'esprit
- que l'authentification Basic transmet le mot de passe depuis le
- client vers le serveur en clair. Cette méthode ne devra donc pas
- être utilisée pour la transmission de données hautement sensibles si
- elle n'est pas associée au module mod_ssl. Apache
- supporte une autre méthode d'authentification : AuthType
- Digest. Cette méthode est implémentée par le module mod_auth_digest et est beaucoup plus sécurisée. La plupart
- des navigateurs récents supportent l'authentification Digest.
La directive AuthName définit
- l'Identificateur (Realm) à utiliser avec
- l'authentification. L'identificateur possède deux fonctions. Tout
- d'abord, le client présente en général cette information à
- l'utilisateur dans le cadre de la boîte de dialogue de mot de passe.
- Ensuite, le client l'utilise pour déterminer quel mot de passe
- envoyer pour une zone authentifiée donnée.
Ainsi par exemple, une fois un client authentifié dans la zone
- "Fichiers réservés", il soumettra à nouveau
- automatiquement le même mot de passe pour toute zone du même serveur
- marquée de l'identificateur "Fichiers réservés". De
- cette façon, vous pouvez éviter à un utilisateur d'avoir à saisir
- plusieurs fois le même mot de passe en faisant partager le même
- identificateur entre plusieurs zones réservées. Bien entendu et pour
- des raisons de sécurité, le client devra redemander le mot
- de passe chaque fois que le nom d'hôte du serveur sera modifié.
La directive AuthBasicProvider est, dans ce
- cas, facultative, car file est la valeur par défaut
- pour cette directive. Par contre, cette directive sera obligatoire
- si vous utilisez une autre source d'authentification comme
- mod_authn_dbm ou
- mod_authn_dbd.
La directive AuthUserFile définit le chemin
- du fichier de mots de passe que nous venons de créer avec
- htpasswd. Si vous possédez un grand nombre
- d'utilisateurs, la durée de la recherche dans un fichier texte pour
- authentifier un utilisateur à chaque requête va augmenter
- rapidement, et pour pallier cet inconvénient, Apache peut aussi
- stocker les données relatives aux
- utilisateurs dans des bases de données rapides. Le module
- mod_authn_dbm fournit la directive AuthDBMUserFile. Le programme dbmmanage permet de créer et manipuler ces fichiers. Vous
- trouverez de nombreuses options d'autres types d'authentification
- fournies par des modules tiers dans la Base de données des modules
- d'Apache.
Enfin, la directive Require implémente la partie
- autorisation du processus en définissant l'utilisateur autorisé à
- accéder à cette zone du serveur. Dans la section suivante, nous
- décrirons les différentes méthodes d'utilisation de la directive
- Require.
Les directives ci-dessus n'autorisent qu'une personne (quelqu'un
- possédant le nom d'utilisateur rbowen) à accéder au
- répertoire. Dans la plupart des cas, vous devrez autoriser
- l'accès à plusieurs personnes. C'est ici
- qu'intervient la directive AuthGroupFile.
Si vous voulez autoriser l'accès à plusieurs personnes, vous - devez créer un fichier de groupes qui associe des noms de groupes - avec une liste d'utilisateurs de ce groupe. Le format de ce fichier - est très simple, et vous pouvez le créer avec votre éditeur favori. - Son contenu se présente comme suit :
- -
- Nom-de-groupe: rbowen dpitts sungo rshersey
-
Il s'agit simplement une liste des membres du groupe sous la - forme d'une ligne séparée par des espaces.
- -Pour ajouter un utilisateur à votre fichier de mots de passe - préexistant, entrez :
- -
- htpasswd /usr/local/apache/passwd/passwords dpitts
-
Vous obtiendrez le même effet qu'auparavant, mais le mot de passe
- sera ajouté au fichier, plutôt que d'en créer un nouveau (C'est le
- drapeau -c qui permet de créer un nouveau fichier de
- mots de passe)..
Maintenant, vous devez modifier votre fichier
- .htaccess comme suit :
- AuthType Basic
- AuthName "By Invitation Only"
- # Ligne facultative :
- AuthBasicProvider file
- AuthUserFile /usr/local/apache/passwd/passwords
- AuthGroupFile /usr/local/apache/passwd/groups
- Require group Nom-de-groupe
-
Maintenant, quiconque appartient au groupe
- Nom-de-groupe, et possède une entrée dans le fichier
- password pourra accéder au répertoire s'il tape le bon
- mot de passe.
Il existe une autre méthode moins contraignante pour autoriser - l'accès à plusieurs personnes. Plutôt que de créer un fichier de - groupes, il vous suffit d'ajouter la directive suivante :
- -
- Require valid-user
-
Le remplacement de la ligne Require user rbowen par
- la ligne Require valid-user autorisera l'accès à
- quiconque possédant une entrée dans le fichier password, et ayant
- tapé le bon mot de passe. Vous pouvez même simuler le comportement
- des groupes en associant un fichier de mots de passe différent pour
- chaque groupe. L'avantage de cette approche réside dans le fait
- qu'Apache ne doit consulter qu'un fichier au lieu de deux. Par
- contre, vous devez maintenir un nombre plus ou moins important de
- fichiers de mots de passe, et vous assurer de faire référence au bon
- fichier dans la directive AuthUserFile.
L'authentification Basic est spécifiée d'une telle manière que - vos nom d'utilisateur et mot de passe doivent être vérifiés chaque - fois que vous demandez un document au serveur, et ceci même si vous - rechargez la même page, et pour chaque image contenue dans la page - (si elles sont situées dans un répertoire protégé). Comme vous - pouvez l'imaginer, ceci ralentit un peu le fonctionnement. La mesure - dans laquelle le fonctionnement est ralenti est proportionnelle à la - taille du fichier des mots de passe, car ce dernier doit être ouvert - et la liste des utilisateurs parcourue jusqu'à ce que votre nom soit - trouvé, et ceci chaque fois qu'une page est chargée.
- -En conséquence, ce ralentissement impose une limite pratique au - nombre d'utilisateurs que vous pouvez enregistrer dans un fichier de - mots de passe. Cette limite va varier en fonction des performances - de votre serveur, mais vous commencerez à remarquer un - ralentissement lorsque vous atteindrez quelques centaines - d'utilisateurs, et serez alors appelés à utiliser une méthode - d'authentification différente.
-Suite au problème évoqué précédemment et induit par le stockage - des mots de passe dans un fichier texte, vous pouvez être appelé à - stocker vos mots de passe d'une autre manière, par exemple dans une - base de données.
- -Pour y parvenir, on peut utiliser les modules
- mod_authn_dbm ou mod_authn_dbd.
- Vous pouvez choisir comme format de stockage dbm ou
- dbd à la place de file pour la directive
- AuthBasicProvider.
Par exemple, pour sélectionner un fichier dbm à la place d'un - fichier texte :
- -
- <Directory /www/docs/private>
- AuthName "Private"
- AuthType Basic
- AuthBasicProvider dbm
- AuthDBMUserFile /www/passwords/passwd.dbm
- Require valid-user
- </Directory>
-
D'autres options sont disponibles. Consultez la documentation de
- mod_authn_dbm pour plus de détails.
Depuis l'arrivée des nouvelles architecture d'autorisation et - d'authentification basées sur les fournisseurs, vous n'êtes plus - limité à une méthode d'authentification et d'autorisation - unique. En fait, on peut panacher autant de fournisseurs que l'on - veut, ce qui vous permet d'élaborer l'architecture qui correspond - exactement à vos besoins. Dans l'exemple suivant, on utilise - conjointement les fournisseurs d'authentification - file et LDAP :
- -
- <Directory /www/docs/private>
- AuthName "Private"
- AuthType Basic
- AuthBasicProvider file ldap
- AuthUserFile /usr/local/apache/passwd/passwords
- AuthLDAPURL ldap://ldaphost/o=yourorg
- Require valid-user
- </Directory>
-
Dans cet exemple, le fournisseur file va tenter d'authentifier - l'utilisateur en premier. S'il n'y parvient pas, le fournisseur LDAP - sera sollicité. Ceci permet l'élargissement des possibilités - d'authentification si votre organisation implémente plusieurs types - de bases d'authentification. D'autres scénarios d'authentification - et d'autorisation peuvent associer un type d'authentification avec - un autre type d'autorisation. Par exemple, une authentification - basée sur un fichier de mots de passe peut permettre l'attribution - d'autorisations basée sur un annuaire LDAP.
- -Tout comme plusieurs fournisseurs d'authentification peuvent être - implémentés, on peut aussi utiliser plusieurs méthodes - d'autorisation. Dans l'exemple suivant, on utilise à la fois une - autorisation à base de fichier de groupes et une autorisation à base - de groupes LDAP.
- -
- <Directory /www/docs/private>
- AuthName "Private"
- AuthType Basic
- AuthBasicProvider file
- AuthUserFile /usr/local/apache/passwd/passwords
- AuthLDAPURL ldap://ldaphost/o=yourorg
- AuthGroupFile /usr/local/apache/passwd/groups
- Require group GroupName
- Require ldap-group cn=mygroup,o=yourorg
- </Directory>
-
Pour un scénario d'autorisation un peu plus avancé, des
- directives de conteneur d'autorisation comme <RequireAll> et
- <RequireAny> permettent d'appliquer une
- logique telle que l'ordre dans lequel les autorisations sont
- appliquées peut être entièrement contrôlé au niveau de la
- configuration. Voir Conteneurs
- d'autorisations pour un exemple de ce contrôle.
La manière dont les autorisations sont accordées est désormais - beaucoup plus souple qu'une simple vérification auprès d'une seule - base de données. Il est maintenant possible de choisir l'ordre, la - logique et la manière selon lesquels une autorisation est - accordée.
- -Le contrôle de la manière et de l'ordre selon lesquels le
- processus d'autorisation était appliqué
- constituait une sorte de mystère par
- le passé. Dans Apache 2.2, un mécanisme d'authentification basé
- sur les fournisseurs a été développé afin de séparer le
- véritable processus d'authentification de l'autorisation et ses
- différentes fonctionnalités. Un des avantages colatéraux
- résidait dans le fait que les fournisseurs d'authentification
- pouvaient être configurés et appelés selon un ordre particulier
- indépendant de l'ordre de chargement du module auth proprement
- dit. Ce mécanisme basé sur les fournisseurs a été étendu au
- processus d'autorisation. Ceci signifie que la directive
- Require définit
- non seulement quelles méthodes d'autorisation doivent être
- utilisées, mais aussi l'ordre dans lequel elles sont appelées.
- Les méthodes d'autorisation sont appelées selon l'ordre dans
- lequel les directives Require apparaissent dans la
- configuration.
Avec l'introduction des directives de conteneur
- d'autorisations <RequireAll>
- et <RequireAny>, la
- configuration contrôle aussi le moment où les méthodes
- d'autorisation sont appelées, et quels critères déterminent
- l'autorisation d'accès. Voir Conteneurs
- d'autorisations pour un exemple de la manière de les
- utiliser pour exprimer des logiques d'autorisation
- complexes.
Par défaut, toutes les directives Require sont
- traitées comme si elles étaient contenues dans une directive
- <RequireAny>. En d'autres termes, il
- suffit
- qu'une méthode d'autorisation s'applique avec succès pour que
- l'autorisation soit accordée.
La vérification du nom d'utilisateur et du mot de passe ne - constituent qu'un aspect des méthodes d'authentification. - Souvent, le contrôle d'accès à certaines personnes n'est pas - basé sur leur identité ; il peut dépendre, par exemple de leur - provenance.
- -Les fournisseurs d'autorisation
- all,
- env,
- host et
- ip vous permettent d'accorder ou refuser l'accès en
- fonction de critères tels que le nom d'hôte ou l'adresse
- IP de la machine qui effectue la requête.
L'utilisation de ces fournisseurs est spécifiée à l'aide de
- la directive Require. Cette directive
- permet d'enregistrer quels fournisseurs d'autorisation
- seront appelés dans le processus d'autorisation au cours du
- traitement de la requête. Par exemple :
- Require ip adresse
-
où adresse est une adresse IP (ou une adresse IP - partielle) ou :
- -
- Require host nom_domaine
-
où nom_domaine est un nom de domaine entièrement - qualifé (ou un nom de domaine partiel) ; vous pouvez indiquer - plusieurs adresses ou noms de domaines, si vous le désirez.
- -Par exemple, si vous voulez rejeter les spams dont une - machine vous inonde, vous pouvez utiliser ceci :
- -
- <RequireAll>
-
- Require all granted
- Require not ip 10.252.46.165
-
- </RequireAll>
-
Ainsi, les visiteurs en provenance de cette adresse ne - pourront pas voir le contenu concerné par cette directive. Si, - par contre, vous connaissez le nom de la machine, vous pouvez - utiliser ceci :
- -
- <RequireAll>
-
- Require all granted
- Require not host serveur.exemple.com
-
- </RequireAll>
-
Et si vous voulez interdire l'accès à toutes les machines - d'un domaine, vous pouvez spécifier une partie seulement de - l'adresse ou du nom de domaine :
- -
- <RequireAll>
-
- Require all granted
- <RequireNone>
-
- Require ip 192.168.205
- Require host phishers.exemple.com autres-idiots.exemple
- Require host ke
-
- </RequireNone>
-
- </RequireAll>
-
Dans l'exemple ci-dessus, on utilise la directive du
- conteneur <RequireNone> afin de s'assurer
- qu'aucune des directives Require qu'il contient ne
- fasse correspondre ses paramètres avant d'accorder
- l'autorisation.
L'adoption d'un mécanisme à base de fournisseurs pour
- l'authentification, a pour effet colatéral de rendre inutiles
- les directives Order, Allow, Deny et Satisfy. Cependant, et à
- des fins de compatibilité ascendante vers les anciennes
- configurations, ces directives ont été déplacées vers le module
- mod_access_compat.
Vous pouvez aussi lire la documentation de
- mod_auth_basic et mod_authz_host
- qui contient des informations supplémentaires à propos du
- fonctionnement de tout ceci.
- Certaines configurations d'authentification peuvent aussi être
- simplifiées à l'aide de la directive <AuthnProviderAlias>.
Les différents algorithmes de chiffrement supportés par Apache - pour authentifier les données sont expliqués dans PasswordEncryptions.
- -Enfin vous pouvez consulter la recette Contrôle - d'accès, qui décrit un certain nombre de situations en relation - avec le sujet.
- -Serveur Apache HTTP Version 2.3
+L'authentification est un processus qui vous permet de vérifier + qu'une personne est bien celle qu'elle prétend être. L'autorisation + est un processus qui permet à une personne d'aller là où elle veut + aller, ou d'obtenir les informations qu'elle désire.
+ Modules et directives concernés Introduction Les prérequis Mise en oeuvre Autorisation d'accès à
+plusieurs personnes Problèmes possibles Autre méthode de stockage des mots de
+passe Utilisation de plusieurs fournisseurs
+d'authentification Pour aller plus loin qu'une simple
+autorisation Pour aller plus loin . . .Trois groupes de modules sont concernés par le processus +d'authentification et d'autorisation. Vous devrez utiliser au moins un +module de chaque groupe.
+ +AuthType)
+
+ AuthBasicProvider et AuthDigestProvider)
+
+
+ Require)
+
+ On peut aussi ajouter mod_authn_core et
+ mod_authz_core. Ces modules implémentent des
+ directives générales qui opèrent au dessus de tous les modules
+ d'authentification.
Le module mod_authnz_ldap est un fournisseur
+ d'authentification et d'autorisation. Le module
+ mod_authz_host fournit une autorisation et un
+ contrôle d'accès basés sur le nom du serveur, l'adresse IP ou
+ certaines caractéristiques de la requête, mais ne fait pas partie du
+ système fournisseur d'authentification. Le module
+ mod_access_compat a été créé à des fins de
+ compatibilité ascendante avec mod_access.
Vous devriez aussi jeter un coup d'oeil au manuel de recettes de Contrôle d'accès, qui décrit les différentes + méthodes de contrôle d'accès à votre serveur.
+ +Si votre site web contient des informations sensibles ou + destinées seulement à un groupe de personnes restreint, les + techniques exposées dans cet article vont vous aider à vous assurer + que les personnes qui ont accès à ces pages sont bien celles + auxquelles vous avez donné l'autorisation d'accès.
+ +Cet article décrit les méthodes "standards" de protection de + parties de votre site web que la plupart d'entre vous sont appelés à + utiliser.
+ +Si vos données ont un réel besoin de sécurisation, prévoyez
+ l'utilisation de mod_ssl en plus de toute méthode
+ d'authentification.
Les directives décrites dans cet article devront être insérées
+ soit au niveau de la configuration de votre serveur principal (en
+ général dans une section <Directory>), soit au niveau de la
+ configuration des répertoires (fichiers .htaccess)
Si vous envisagez l'utilisation de fichiers
+ .htaccess, la configuration de votre serveur devra
+ permettre l'ajout de directives d'authentification dans ces
+ fichiers. Pour ce faire, on utilise la directive AllowOverride, qui spécifie quelles
+ directives pourront éventuellement contenir les fichiers de
+ configuration de niveau répertoire.
Comme il est ici question d'authentification, vous aurez besoin
+ d'une directive AllowOverride
+ du style :
+ AllowOverride AuthConfig
+
Si vous avez l'intention d'ajouter les directives directement + dans le fichier de configuration principal, vous devrez bien entendu + posséder les droits en écriture sur ce fichier.
+ +Vous devrez aussi connaître un tant soit peu la structure des + répertoires de votre serveur, ne serait-ce que pour savoir où se + trouvent certains fichiers. Cela ne devrait pas présenter de grandes + difficultés, et nous essaierons de clarifier tout ça lorsque le besoin + s'en fera sentir.
+ +Enfin, vous devrez vous assurer que les modules
+ mod_authn_core et mod_authz_core
+ ont été soit compilés avec le binaire httpd, soit chargés par le
+ fichier de configuration httpd.conf. Ces deux modules fournissent
+ des directives générales et des fonctionnalités qui sont critiques
+ quant à la configuration et l'utilisation de l'authentification et
+ de l'autorisation au sein du serveur web.
Nous décrivons ici les bases de la protection par mot de passe + d'un répertoire de votre serveur.
+ +Vous devez en premier lieu créer un fichier de mots de passe. La + méthode exacte selon laquelle vous allez créer ce fichier va varier + en fonction du fournisseur d'authentification choisi. Mais nous + entrerons dans les détails plus loin, et pour le moment, nous nous + contenterons d'un fichier de mots de passe en mode texte.
+ +Ce fichier doit être enregistré à un endroit non accessible
+ depuis le web, de façon à ce que les clients ne puissent pas le
+ télécharger. Par exemple, si vos documents sont servis à partir de
+ /usr/local/apache/htdocs, vous pouvez enregistrer le
+ fichier des mots de passe dans
+ /usr/local/apache/passwd.
L'utilitaire htpasswd fourni avec Apache
+ permet de créer ce fichier. Vous le trouverez dans le répertoire
+ bin de votre installation d'Apache. Si vous avez
+ installé Apache à partir d'un paquetage tiers, il sera probablement
+ dans le chemin par défaut de vos exécutables.
Pour créer le fichier, tapez :
+ +
+ htpasswd -c /usr/local/apache/passwd/passwords rbowen
+
htpasswd vous demandera d'entrer le mot de
+ passe, et de le retaper pour confirmation :
+ # htpasswd -c /usr/local/apache/passwd/passwords rbowen
+ New password: mot-de-passe
+ Re-type new password: mot-de-passe
+ Adding password for user rbowen
+
Si htpasswd n'est pas dans le chemin par
+ défaut de vos exécutables, vous devrez bien entendu entrer le chemin
+ complet du fichier. Dans le cas d'une installation par défaut, il se
+ trouve à /usr/local/apache2/bin/htpasswd.
Ensuite, vous allez devoir configurer le serveur de façon à ce
+ qu'il demande un mot de passe et lui préciser quels utilisateurs ont
+ l'autorisation d'accès. Pour ce faire, vous pouvez soit éditer le
+ fichier httpd.conf, soit utiliser un fichier
+ .htaccess. Par exemple, si vous voulez protéger le
+ répertoire /usr/local/apache/htdocs/secret, vous pouvez
+ utiliser les directives suivantes, soit dans le fichier
+ /usr/local/apache/htdocs/secret/.htaccess, soit dans le
+ fichier httpd.conf à l'intérieur d'une section <Directory
+ /usr/local/apache/htdocs/secret> :
+ AuthType Basic
+ AuthName "Fichiers réservés"
+ # (La ligne suivante est facultative)
+ AuthBasicProvider file
+ AuthUserFile /usr/local/apache/passwd/passwords
+ Require user rbowen
+
Examinons ces directives une à une. La directive AuthType définit la méthode
+ utilisée pour authentifier l'utilisateur. La méthode la plus
+ courante est Basic, et elle est implémentée par
+ mod_auth_basic. Il faut cependant garder à l'esprit
+ que l'authentification Basic transmet le mot de passe depuis le
+ client vers le serveur en clair. Cette méthode ne devra donc pas
+ être utilisée pour la transmission de données hautement sensibles si
+ elle n'est pas associée au module mod_ssl. Apache
+ supporte une autre méthode d'authentification : AuthType
+ Digest. Cette méthode est implémentée par le module mod_auth_digest et est beaucoup plus sécurisée. La plupart
+ des navigateurs récents supportent l'authentification Digest.
La directive AuthName définit
+ l'Identificateur (Realm) à utiliser avec
+ l'authentification. L'identificateur possède deux fonctions. Tout
+ d'abord, le client présente en général cette information à
+ l'utilisateur dans le cadre de la boîte de dialogue de mot de passe.
+ Ensuite, le client l'utilise pour déterminer quel mot de passe
+ envoyer pour une zone authentifiée donnée.
Ainsi par exemple, une fois un client authentifié dans la zone
+ "Fichiers réservés", il soumettra à nouveau
+ automatiquement le même mot de passe pour toute zone du même serveur
+ marquée de l'identificateur "Fichiers réservés". De
+ cette façon, vous pouvez éviter à un utilisateur d'avoir à saisir
+ plusieurs fois le même mot de passe en faisant partager le même
+ identificateur entre plusieurs zones réservées. Bien entendu et pour
+ des raisons de sécurité, le client devra redemander le mot
+ de passe chaque fois que le nom d'hôte du serveur sera modifié.
La directive AuthBasicProvider est, dans ce
+ cas, facultative, car file est la valeur par défaut
+ pour cette directive. Par contre, cette directive sera obligatoire
+ si vous utilisez une autre source d'authentification comme
+ mod_authn_dbm ou
+ mod_authn_dbd.
La directive AuthUserFile définit le chemin
+ du fichier de mots de passe que nous venons de créer avec
+ htpasswd. Si vous possédez un grand nombre
+ d'utilisateurs, la durée de la recherche dans un fichier texte pour
+ authentifier un utilisateur à chaque requête va augmenter
+ rapidement, et pour pallier cet inconvénient, Apache peut aussi
+ stocker les données relatives aux
+ utilisateurs dans des bases de données rapides. Le module
+ mod_authn_dbm fournit la directive AuthDBMUserFile. Le programme dbmmanage permet de créer et manipuler ces fichiers. Vous
+ trouverez de nombreuses options d'autres types d'authentification
+ fournies par des modules tiers dans la Base de données des modules
+ d'Apache.
Enfin, la directive Require implémente la partie
+ autorisation du processus en définissant l'utilisateur autorisé à
+ accéder à cette zone du serveur. Dans la section suivante, nous
+ décrirons les différentes méthodes d'utilisation de la directive
+ Require.
Les directives ci-dessus n'autorisent qu'une personne (quelqu'un
+ possédant le nom d'utilisateur rbowen) à accéder au
+ répertoire. Dans la plupart des cas, vous devrez autoriser
+ l'accès à plusieurs personnes. C'est ici
+ qu'intervient la directive AuthGroupFile.
Si vous voulez autoriser l'accès à plusieurs personnes, vous + devez créer un fichier de groupes qui associe des noms de groupes + avec une liste d'utilisateurs de ce groupe. Le format de ce fichier + est très simple, et vous pouvez le créer avec votre éditeur favori. + Son contenu se présente comme suit :
+ +
+ Nom-de-groupe: rbowen dpitts sungo rshersey
+
Il s'agit simplement une liste des membres du groupe sous la + forme d'une ligne séparée par des espaces.
+ +Pour ajouter un utilisateur à votre fichier de mots de passe + préexistant, entrez :
+ +
+ htpasswd /usr/local/apache/passwd/passwords dpitts
+
Vous obtiendrez le même effet qu'auparavant, mais le mot de passe
+ sera ajouté au fichier, plutôt que d'en créer un nouveau (C'est le
+ drapeau -c qui permet de créer un nouveau fichier de
+ mots de passe)..
Maintenant, vous devez modifier votre fichier
+ .htaccess comme suit :
+ AuthType Basic
+ AuthName "By Invitation Only"
+ # Ligne facultative :
+ AuthBasicProvider file
+ AuthUserFile /usr/local/apache/passwd/passwords
+ AuthGroupFile /usr/local/apache/passwd/groups
+ Require group Nom-de-groupe
+
Maintenant, quiconque appartient au groupe
+ Nom-de-groupe, et possède une entrée dans le fichier
+ password pourra accéder au répertoire s'il tape le bon
+ mot de passe.
Il existe une autre méthode moins contraignante pour autoriser + l'accès à plusieurs personnes. Plutôt que de créer un fichier de + groupes, il vous suffit d'ajouter la directive suivante :
+ +
+ Require valid-user
+
Le remplacement de la ligne Require user rbowen par
+ la ligne Require valid-user autorisera l'accès à
+ quiconque possédant une entrée dans le fichier password, et ayant
+ tapé le bon mot de passe. Vous pouvez même simuler le comportement
+ des groupes en associant un fichier de mots de passe différent pour
+ chaque groupe. L'avantage de cette approche réside dans le fait
+ qu'Apache ne doit consulter qu'un fichier au lieu de deux. Par
+ contre, vous devez maintenir un nombre plus ou moins important de
+ fichiers de mots de passe, et vous assurer de faire référence au bon
+ fichier dans la directive AuthUserFile.
L'authentification Basic est spécifiée d'une telle manière que + vos nom d'utilisateur et mot de passe doivent être vérifiés chaque + fois que vous demandez un document au serveur, et ceci même si vous + rechargez la même page, et pour chaque image contenue dans la page + (si elles sont situées dans un répertoire protégé). Comme vous + pouvez l'imaginer, ceci ralentit un peu le fonctionnement. La mesure + dans laquelle le fonctionnement est ralenti est proportionnelle à la + taille du fichier des mots de passe, car ce dernier doit être ouvert + et la liste des utilisateurs parcourue jusqu'à ce que votre nom soit + trouvé, et ceci chaque fois qu'une page est chargée.
+ +En conséquence, ce ralentissement impose une limite pratique au + nombre d'utilisateurs que vous pouvez enregistrer dans un fichier de + mots de passe. Cette limite va varier en fonction des performances + de votre serveur, mais vous commencerez à remarquer un + ralentissement lorsque vous atteindrez quelques centaines + d'utilisateurs, et serez alors appelés à utiliser une méthode + d'authentification différente.
+Suite au problème évoqué précédemment et induit par le stockage + des mots de passe dans un fichier texte, vous pouvez être appelé à + stocker vos mots de passe d'une autre manière, par exemple dans une + base de données.
+ +Pour y parvenir, on peut utiliser les modules
+ mod_authn_dbm ou mod_authn_dbd.
+ Vous pouvez choisir comme format de stockage dbm ou
+ dbd à la place de file pour la directive
+ AuthBasicProvider.
Par exemple, pour sélectionner un fichier dbm à la place d'un + fichier texte :
+ +
+ <Directory /www/docs/private>
+ AuthName "Private"
+ AuthType Basic
+ AuthBasicProvider dbm
+ AuthDBMUserFile /www/passwords/passwd.dbm
+ Require valid-user
+ </Directory>
+
D'autres options sont disponibles. Consultez la documentation de
+ mod_authn_dbm pour plus de détails.
Depuis l'arrivée des nouvelles architecture d'autorisation et + d'authentification basées sur les fournisseurs, vous n'êtes plus + limité à une méthode d'authentification et d'autorisation + unique. En fait, on peut panacher autant de fournisseurs que l'on + veut, ce qui vous permet d'élaborer l'architecture qui correspond + exactement à vos besoins. Dans l'exemple suivant, on utilise + conjointement les fournisseurs d'authentification + file et LDAP :
+ +
+ <Directory /www/docs/private>
+ AuthName "Private"
+ AuthType Basic
+ AuthBasicProvider file ldap
+ AuthUserFile /usr/local/apache/passwd/passwords
+ AuthLDAPURL ldap://ldaphost/o=yourorg
+ Require valid-user
+ </Directory>
+
Dans cet exemple, le fournisseur file va tenter d'authentifier + l'utilisateur en premier. S'il n'y parvient pas, le fournisseur LDAP + sera sollicité. Ceci permet l'élargissement des possibilités + d'authentification si votre organisation implémente plusieurs types + de bases d'authentification. D'autres scénarios d'authentification + et d'autorisation peuvent associer un type d'authentification avec + un autre type d'autorisation. Par exemple, une authentification + basée sur un fichier de mots de passe peut permettre l'attribution + d'autorisations basée sur un annuaire LDAP.
+ +Tout comme plusieurs fournisseurs d'authentification peuvent être + implémentés, on peut aussi utiliser plusieurs méthodes + d'autorisation. Dans l'exemple suivant, on utilise à la fois une + autorisation à base de fichier de groupes et une autorisation à base + de groupes LDAP.
+ +
+ <Directory /www/docs/private>
+ AuthName "Private"
+ AuthType Basic
+ AuthBasicProvider file
+ AuthUserFile /usr/local/apache/passwd/passwords
+ AuthLDAPURL ldap://ldaphost/o=yourorg
+ AuthGroupFile /usr/local/apache/passwd/groups
+ Require group GroupName
+ Require ldap-group cn=mygroup,o=yourorg
+ </Directory>
+
Pour un scénario d'autorisation un peu plus avancé, des
+ directives de conteneur d'autorisation comme <RequireAll> et
+ <RequireAny> permettent d'appliquer une
+ logique telle que l'ordre dans lequel les autorisations sont
+ appliquées peut être entièrement contrôlé au niveau de la
+ configuration. Voir Conteneurs
+ d'autorisations pour un exemple de ce contrôle.
La manière dont les autorisations sont accordées est désormais + beaucoup plus souple qu'une simple vérification auprès d'une seule + base de données. Il est maintenant possible de choisir l'ordre, la + logique et la manière selon lesquels une autorisation est + accordée.
+ +Le contrôle de la manière et de l'ordre selon lesquels le
+ processus d'autorisation était appliqué
+ constituait une sorte de mystère par
+ le passé. Dans Apache 2.2, un mécanisme d'authentification basé
+ sur les fournisseurs a été développé afin de séparer le
+ véritable processus d'authentification de l'autorisation et ses
+ différentes fonctionnalités. Un des avantages colatéraux
+ résidait dans le fait que les fournisseurs d'authentification
+ pouvaient être configurés et appelés selon un ordre particulier
+ indépendant de l'ordre de chargement du module auth proprement
+ dit. Ce mécanisme basé sur les fournisseurs a été étendu au
+ processus d'autorisation. Ceci signifie que la directive
+ Require définit
+ non seulement quelles méthodes d'autorisation doivent être
+ utilisées, mais aussi l'ordre dans lequel elles sont appelées.
+ Les méthodes d'autorisation sont appelées selon l'ordre dans
+ lequel les directives Require apparaissent dans la
+ configuration.
Avec l'introduction des directives de conteneur
+ d'autorisations <RequireAll>
+ et <RequireAny>, la
+ configuration contrôle aussi le moment où les méthodes
+ d'autorisation sont appelées, et quels critères déterminent
+ l'autorisation d'accès. Voir Conteneurs
+ d'autorisations pour un exemple de la manière de les
+ utiliser pour exprimer des logiques d'autorisation
+ complexes.
Par défaut, toutes les directives Require sont
+ traitées comme si elles étaient contenues dans une directive
+ <RequireAny>. En d'autres termes, il
+ suffit
+ qu'une méthode d'autorisation s'applique avec succès pour que
+ l'autorisation soit accordée.
La vérification du nom d'utilisateur et du mot de passe ne + constituent qu'un aspect des méthodes d'authentification. + Souvent, le contrôle d'accès à certaines personnes n'est pas + basé sur leur identité ; il peut dépendre, par exemple de leur + provenance.
+ +Les fournisseurs d'autorisation
+ all,
+ env,
+ host et
+ ip vous permettent d'accorder ou refuser l'accès en
+ fonction de critères tels que le nom d'hôte ou l'adresse
+ IP de la machine qui effectue la requête.
L'utilisation de ces fournisseurs est spécifiée à l'aide de
+ la directive Require. Cette directive
+ permet d'enregistrer quels fournisseurs d'autorisation
+ seront appelés dans le processus d'autorisation au cours du
+ traitement de la requête. Par exemple :
+ Require ip adresse
+
où adresse est une adresse IP (ou une adresse IP + partielle) ou :
+ +
+ Require host nom_domaine
+
où nom_domaine est un nom de domaine entièrement + qualifé (ou un nom de domaine partiel) ; vous pouvez indiquer + plusieurs adresses ou noms de domaines, si vous le désirez.
+ +Par exemple, si vous voulez rejeter les spams dont une + machine vous inonde, vous pouvez utiliser ceci :
+ +
+ <RequireAll>
+
+ Require all granted
+ Require not ip 10.252.46.165
+
+ </RequireAll>
+
Ainsi, les visiteurs en provenance de cette adresse ne + pourront pas voir le contenu concerné par cette directive. Si, + par contre, vous connaissez le nom de la machine, vous pouvez + utiliser ceci :
+ +
+ <RequireAll>
+
+ Require all granted
+ Require not host serveur.exemple.com
+
+ </RequireAll>
+
Et si vous voulez interdire l'accès à toutes les machines + d'un domaine, vous pouvez spécifier une partie seulement de + l'adresse ou du nom de domaine :
+ +
+ <RequireAll>
+
+ Require all granted
+ <RequireNone>
+
+ Require ip 192.168.205
+ Require host phishers.exemple.com autres-idiots.exemple
+ Require host ke
+
+ </RequireNone>
+
+ </RequireAll>
+
Dans l'exemple ci-dessus, on utilise la directive du
+ conteneur <RequireNone> afin de s'assurer
+ qu'aucune des directives Require qu'il contient ne
+ fasse correspondre ses paramètres avant d'accorder
+ l'autorisation.
L'adoption d'un mécanisme à base de fournisseurs pour
+ l'authentification, a pour effet colatéral de rendre inutiles
+ les directives Order, Allow, Deny et Satisfy. Cependant, et à
+ des fins de compatibilité ascendante vers les anciennes
+ configurations, ces directives ont été déplacées vers le module
+ mod_access_compat.
Vous pouvez aussi lire la documentation de
+ mod_auth_basic et mod_authz_host
+ qui contient des informations supplémentaires à propos du
+ fonctionnement de tout ceci.
+ Certaines configurations d'authentification peuvent aussi être
+ simplifiées à l'aide de la directive <AuthnProviderAlias>.
Les différents algorithmes de chiffrement supportés par Apache + pour authentifier les données sont expliqués dans PasswordEncryptions.
+ +Enfin vous pouvez consulter la recette Contrôle + d'accès, qui décrit un certain nombre de situations en relation + avec le sujet.
+ +Serveur Apache HTTP Version 2.3
-| Modules Apparentés | Directives Apparentées |
|---|---|
CGI (Common Gateway Interface) définit une méthode d'interaction - entre un serveur web et des programmes générateurs de contenu - externes, plus souvent appelés programmes CGI ou scripts CGI. Il - s'agit de la méthode la plus simple, et la plus - courante, pour ajouter du contenu dynamique à votre site web. Ce - document est une introduction à la configuration de CGI sur votre - serveur web Apache, et une initiation à l'écriture de programmes - CGI.
-Apache doit être configuré pour permettre l'exécution des - programmes CGI, pour que vos programmes CGI puissent fonctionner - correctement. Il existe plusieurs méthodes pour y parvenir.
- -LoadModule correspondante n'a pas été
- commentée dans votre httpd.conf. Une directive correcte
- doit ressembler à ceci :
-
-
- LoadModule cgi_module modules/mod_cgi.so
-
La directive ScriptAlias indique à Apache qu'un
- répertoire particulier est dédié aux programmes CGI. Apache
- considérera que tout fichier situé dans ce répertoire est un
- programme CGI, et tentera de l'exécuter lorsque cette ressource
- fera l'objet d'une requête client.
La directive ScriptAlias se présente comme suit
- :
- ScriptAlias /cgi-bin/ /usr/local/apache2/cgi-bin/
-
Cet exemple est tiré de votre fichier de configuration
- httpd.conf par défaut, si vous avez installé Apache
- dans son répertoire par défaut. La directive ScriptAlias est similaire à la
- directive Alias, qui
- définit à quel répertoire particulier doit correspondre un préfixe
- d'URL. Alias et
- ScriptAlias sont généralement utilisés pour
- accéder à des répertoires situés en dehors du répertoire défini
- par la directive DocumentRoot. La différence entre
- Alias et ScriptAlias
- réside dans le fait que ScriptAlias indique
- en plus que tout ce qui se trouve sous le préfixe d'URL doit être
- considéré comme un programme CGI. Ainsi, l'exemple ci-dessus
- indique à Apache que toute requête pour une ressource commençant
- par /cgi-bin/ doit être servie depuis le répertoire
- /usr/local/apache2/cgi-bin/, et doit être traitée en
- tant que programme CGI.
Par exemple, si une requête pour l'URL
- http://www.example.com/cgi-bin/test.pl est
- effectuée, Apache tentera d'exécuter le fichier
- /usr/local/apache2/cgi-bin/test.pl et en renverra la
- sortie. Bien entendu, le fichier doit exister, être exécutable, et
- retourner sa sortie d'une manière particulière, sinon Apache
- renverra un message d'erreur.
Pour des raisons de sécurité, la localisation des programmes
- CGI est souvent restreinte aux
- répertoires définis par ScriptAlias. De cette manière, les administrateurs
- peuvent contrôler précisément qui est autorisé à utiliser les
- programmes CGI. Cependant, si les précautions adéquates quant à
- la sécurité sont prises, il n'y a aucune raison pour que les
- programmes CGI ne puissent pas être exécutés depuis d'autres
- répertoires. Par exemple, vous pouvez autoriser les utilisateurs à
- enregistrer des contenus web dans leurs répertoires home à l'aide
- de la directive UserDir. S'ils veulent mettre en
- oeuvre leurs propres programmes CGI, mais n'ont pas l'autorisation
- d'accès au répertoire cgi-bin principal, ils devront
- être en mesure d'exécuter ces programmes depuis un autre
- répertoire.
L'autorisation d'exécution des programmes CGI dans un
- répertoire arbitraire se fait en deux étapes. En premier lieu, le
- gestionnaire cgi-script doit être activé à l'aide
- d'une directive AddHandler ou SetHandler. En second lieu,
- ExecCGI doit être spécifié dans la directive Options.
Vous pouvez utiliser de manière explicite la directive
- Options dans le fichier de
- configuration de votre serveur principal, pour indiquer que
- l'exécution des programmes CGI est permise depuis un répertoire
- particulier :
- <Directory /usr/local/apache2/htdocs/un-repertoire>
-
- Options +ExecCGI
-
- </Directory>
-
La directive ci-dessus indique à Apache qu'il doit permettre
- l'exécution des fichiers CGI. Vous devez aussi indiquer au serveur
- quels fichiers sont des fichiers CGI. La directive AddHandler suivante indique au
- serveur qu'il doit traiter tous les fichiers possédant une
- extension cgi ou pl en tant que
- programmes CGI :
- AddHandler cgi-script .cgi .pl
-
Le tutoriel
- .htaccess montre comment activer les programmes
- CGI si vous n'avez pas accès au
- fichier httpd.conf.
Pour permettre l'exécution en tant que programme CGI de tout
- fichier possédant l'extension .cgi et situé dans un
- répertoire utilisateur, vous pouvez utiliser la configuration
- suivante :
- <Directory /home/*/public_html>
-
- Options +ExecCGI
- AddHandler cgi-script .cgi
-
- </Directory>
-
Pour indiquer un sous-répertoire cgi-bin d'un
- répertoire utilisateur où tout fichier sera traité en tant que
- programme CGI, vous pouvez utiliser ceci :
- <Directory /home/*/public_html/cgi-bin>
-
- Options ExecCGI
- SetHandler cgi-script
-
- </Directory>
-
Il y a deux différences principales entre la programmation - "standard" et la programmation CGI.
- -En premier lieu, toute sortie de votre programme CGI doit être - précédée d'un en-tête MIME-type. Il s'agit d'un - en-tête HTTP qui indique au client quel type de contenu il reçoit. - La plupart du temps, il se présente comme suit :
- -
- Content-type: text/html
-
En second lieu, votre sortie doit être en HTML, ou tout autre - format qu'un navigateur est en mesure d'afficher. La plupart du - temps, il s'agira de HTML, mais occasionnellement, vous pouvez être - amené à écrire un programme CGI qui renvoie une image gif, ou un - autre type de contenu non-HTML.
- -A part ces deux différences, un programme CGI ressemblera à tout - autre programme que vous pourriez être amené à écrire.
- -L'exemple suivant est un exemple de programme CGI qui permet
- d'afficher une ligne de caractères dans votre navigateur. Ecrivez
- ce qui suit, enregistrez le dans un fichier nommé
- premier.pl, et placez le dans votre répertoire
- cgi-bin.
- #!/usr/bin/perl
- print "Content-type: text/html\n\n";
- print "Bonjour tout le monde . . .";
-
Même si Perl ne vous est pas familier, vous devriez être
- capable de comprendre le fonctionnement de ce programme. La
- première ligne indique à Apache (ou à toute interface à partir de
- laquelle le programme s'exécute) que ce programme peut être
- exécuté en fournissant son fichier à l'interpréteur
- /usr/bin/perl. La seconde ligne affiche la
- déclaration du type de contenu considéré, suivie de deux paires
- "Retour chariot - Nouvelle ligne". Ceci a pour effet d'insérer une
- ligne vide après l'en-tête pour marquer la fin des en-têtes HTTP,
- et le début du corps du document. La troisième ligne affiche la
- chaîne de caractères "Bonjour tout le monde . . .". Et c'est tout
- ce dont vous avez besoin.
Si vous ouvrez votre navigateur favori et lui indiquez - l'adresse
- -
- http://www.exemple.com/cgi-bin/premier.pl
-
ou toute autre URL correspondant à votre programme CGI, Vous
- verrez la ligne Bonjour tout le monde . . .
- s'afficher dans la fenêtre de votre navigateur. Ce n'est pas
- extraordinaire, mais si vous y êtes parvenu, vous avez de bonnes
- chances d'y parvenir pour tout autre programme plus
- sophistiqué.
Vous devriez voir au moins une des quatre sorties suivantes dans - votre navigateur lorsque vous essayez d'accéder à votre programme - CGI depuis le web :
- -Content-Type de manière appropriée dans votre
- programme CGI.Souvenez-vous que le serveur ne s'exécute pas sous votre nom.
- En d'autres termes, lorsque le serveur a démarré, il s'exécute
- avec les droits d'un utilisateur non privilégié - en général
- nobody, ou www - et en conséquence, il
- aura besoin de droits supplémentaires pour pouvoir exécuter des
- fichiers dont vous êtes le propriétaire. En général, pour qu'un
- fichier ait des droits suffisants pour être exécutable par
- nobody, il suffit de lui attribuer des droits
- d'exécution pour tout le monde :
- chmod a+x premier.pl
-
En outre, si votre programme doit pouvoir accéder en lecture - et/ou écriture à d'autres fichiers, ces derniers devront avoir les - droits appropriés.
- - - -Lorsque vous lancez un programme depuis la ligne de commande,
- certaines informations sont passées au shell sans que vous vous en
- doutiez. Par exemple, la variable PATH indique au
- shell où il doit rechercher les exécutables auxquels vous faites
- référence.
Lorsqu'un programme s'exécute depuis le serveur web en tant que
- programme CGI, sa variable PATH n'aura peut-être pas
- la même valeur. Tout programme que vous invoquez dans votre
- programme CGI ( comme par exemple sendmail) devra
- être spécifié par son chemin complet, de façon à ce que le shell
- puisse le trouver lorsqu'il tentera d'exécuter votre programme
- CGI.
Un exemple typique de spécification de programme est le chemin
- vers l'interpréteur de script (souvent perl) que l'on
- trouve à la première ligne de votre programme CGI et qui va
- ressembler à ceci :
- #!/usr/bin/perl
-
Assurez-vous qu'il s'agit bien du chemin correct vers - l'interpréteur.
- -De plus, si votre programme CGI dépend d'autres variables d'environnement, vous devrez vous - assurer qu'elles lui sont bien transmises par Apache.
- - - -La plupart des échecs dans l'exécution d'un programme CGI - proviennent du programme lui-même. Ceci est particulièrement vrai - lorsque ce satané programme CGI se bloque, alors que vous avez - appris à ne plus commettre les deux erreurs précédentes. La - première chose à faire est de vous assurer que votre programme - s'exécute depuis la ligne de commande, avant de le tester à partir - du serveur web. Par exemple, essayez :
- -
- cd /usr/local/apache2/cgi-bin
- ./premier.pl
-
(N'invoquez pas l'interpréteur perl. Le shell et
- Apache doivent être capable de le déterminer à partir de l'information sur le chemin située sur
- la première ligne du script.)
La première chose que vous devriez voir affichée par votre
- programme est un ensemble d'en-têtes HTTP, comprenant entre autres
- le Content-Type, et suivi d'une ligne vide. Si vous
- voyez quoi que ce soit d'autre, Apache renverra l'erreur
- Premature end of script headers si vous tentez
- d'exécuter le programme depuis le serveur. Voir Ecriture d'un programme CGI ci-dessus pour
- plus de détails.
Les journaux d'erreurs sont vos amis. Toute anomalie de - fonctionnement est consignée dans le journal des erreurs et c'est - ici que vous devez regarder en premier en cas de problème. Si - l'hébergeur de votre site ne vous donne pas accès au journal des - erreurs, vous avez tout intérêt à vous tourner vers quelqu'un - d'autre. Apprenez à déchiffrer les journaux d'erreurs, et vous - vous apercevrez que la plupart des problèmes seront rapidement - identifiés . . . et résolus.
- - -Le programme suexec permet
- d'exécuter les programmes CGI avec des droits différents selon le
- serveur virtuel ou le répertoire utilisateur dans lequel ils
- se situent. Suexec effectue une vérification des droits très
- stricte, et toute anomalie détectée au cours de cette vérification
- entraînera un echec d'exécution de votre programme CGI avec
- affichage de l'erreur Premature end of script
- headers.
Pour savoir si vous pouvez utiliser suexec, tapez la commande
- apachectl -V, et regardez le chemin indiqué par
- SUEXEC_BIN. Si au démarrage d'Apache, ce dernier
- trouve un exécutable suexec dans ce chemin,
- suexec sera activé.
Si vous ne maîtrisez pas le fonctionnement de suexec, il vous
- est déconseillé de l'utiliser. Pour désactiver suexec, supprimer
- simplement (ou renommez) l'exécutable suexec
- pointé par SUEXEC_BIN et redémarrez le serveur. Si
- après une lecture de suexec, vous
- décidez quand-même de l'utiliser, tapez la commande suexec
- -V pour voir où se situe le journal de suexec, et utilisez
- ce dernier pour déterminer quelles règles vous violez
- éventuellement.
Lorsque vos compétences en programmation CGI seront plus - poussées, il s'avérera intéressant pour vous de mieux comprendre ce - qui se passe en coulisse, et en particulier la manière dont le - navigateur et le serveur dialoguent entre eux. En effet, bien qu'il - soit tout à fait louable d'écrire un programme qui affiche "Bonjour - tout le monde . . .", cela ne sert pas à grand chose.
- -Les variables d'environnement sont des valeurs qui gravitent
- autour de vous lorsque vous utilisez votre ordinateur. Elles sont
- très utiles, à l'instar de votre chemin par défaut (où votre
- ordinateur va rechercher le fichier physique correspondant à la
- commande que vous avez tapée), votre nom d'utilisateur, le type de
- votre terminal, etc... Pour obtenir une liste complète des
- variables d'environnement standards que vous utilisez tous les
- jours, tapez env dans votre interpréteur
- de commandes.
Au cours de la transaction CGI, le serveur et le navigateur - définissent aussi des variables d'environnement, de façon à ce - qu'ils puissent communiquer entre eux. Ces variables définissent - entre autre le type de navigateur (Netscape, IE, Lynx), le type de - serveur (Apache, IIS, WebSite), le nom du programme CGI en cours - d'exécution, etc...
- -Ces variables sont à la disposition du programmeur CGI, et - elles constituent 50% de la communication client-serveur. La liste - complète des variables requises se trouve à - http://hoohoo.ncsa.uiuc.edu/cgi/env.html.
- -Ce programme CGI basique en Perl permet d'afficher toutes les
- variables d'environnement qui sont échangées. Deux programmes
- similaires sont fournis avec la distribution d'Apache et situés
- dans le répertoire cgi-bin.
- Notez que certaines variables sont
- obligatoires, alors que d'autres sont optionnelles, si bien que
- vous verrez s'afficher certaines variables qui ne font pas partie
- de la liste officielle. De plus, Apache vous propose de nombreuses
- méthodes pour ajouter vos propres
- variables d'environnement aux variables de base fournies par
- défaut.
- #!/usr/bin/perl
- print "Content-type: text/html\n\n";
- foreach $key (keys %ENV) {
-
- print "$key --> $ENV{$key}<br>";
-
- }
-
L'entrée standard (STDIN) et la sortie standard
- (STDOUT) constituent d'autres voies de communication
- entre le client et le serveur. Dans un contexte normal,
- STDIN correspond au clavier, ou à un fichier fourni
- au programme à des fins de traitement, et STDOUT à la
- console ou à l'écran.
Lorsque vous transmettez un formulaire web à un programme CGI
- par la méthode POST, les données de ce formulaire
- sont transcrites dans un format spécial et transmises à votre
- programme CGI via STDIN. Le programme peut alors les
- traiter comme si elles provenaient du clavier ou d'un
- fichier.
Ce "format spécial" est très simple. Un nom de champ et sa - valeur sont reliés entre eux par un signe "égal" (=), et chacune - de ces paires nom champ/valeur est séparée de la suivante par un - "et" commercial (&). Les caractères - spéciaux comme les espaces, les "et" commerciaux, et les signes - "égal" sont convertis en leur équivalent hexadécimal pour éviter - qu'ils ne gâchent le travail. La chaîne contenant les données doit - ressembler à ceci :
- -
- name=Rich%20Bowen&city=Lexington&state=KY&sidekick=Squirrel%20Monkey
-
Vous verrez aussi parfois une chaîne de ce type accolée à une
- URL. Dans ce cas, le serveur enregistre cette chaîne dans la
- variable d'environnement appelée QUERY_STRING. On a
- alors affaire à une requête de type GET. Votre
- formulaire HTML indique laquelle des méthodes GET ou
- POST est utilisée pour transmettre les données, en
- définissant l'attribut METHOD au niveau de la balise
- FORM.
Votre programme est ensuite chargé d'extraire les informations - utiles de cette chaîne. Heureusement, des bibliothèques et des - modules sont à votre disposition pour vous aider à traiter ces - données, et à gérer les différents aspects de votre programme - CGI.
- -Pour écrire un programme CGI, il vous est conseillé d'utiliser - une bibliothèque de code, ou un module, qui effectueront une grande - partie du travail de base pour vous. Ceci vous permettra de diminuer - le nombre d'erreurs et d'accélérer le développement.
- -Si vous écrivez des programmes CGI en Perl, des modules sont à
- votre disposition à CPAN. A ce
- sujet, le module le plus populaire est CGI.pm. Vous
- pouvez aussi essayer CGI::Lite, qui implémente les
- fonctionnalités strictement nécessaires, mais suffisantes pour
- la majorité des programmes.
Si vous écrivez des programmes CGI en C, vous disposez de
- nombreuses options. L'une d'elles est la bibliothèque
- CGIC de http://www.boutell.com/cgic/.
Il existe un grand nombre de ressources CGI sur le web. Vous - pouvez discuter de problèmes CGI avec d'autres utilisateurs dans le - groupe Usenet - comp.infosystems.www.authoring.cgi. En outre, la liste de - diffusion de la Guilde des Ecrivains HTML est une source - intarissable de réponses à vos questions. Vous en saurez plus en - vous rendant à http://www.hwg.org/lists/hwg-servers/.
- -Et bien entendu, vous devez lire la spécification CGI, qui - présente tous les détails en rapport avec les opérations des - programmes CGI. La version originale se trouve au NCSA, et - dans la RFC IETF actuelle Common Gateway - Interface RFC.
- -Lorsque vous postez une question à propos d'un problème CGI que - vous rencontrez, que ce soit dans une liste de diffusion ou dans un - newsgroup, faites en sorte de fournir suffisamment d'informations - sur le problème rencontré, ce que vous attendiez exactement, et en - quoi ce qui se produit est réellement différent de ce que vous - attendiez, quel serveur vous utilisez, en quel langage votre - programme CGI a été écrit, et, si possible, son code source. Ceci - permettra une résolution plus aisée de votre problème.
- -Notez que les questions à propos de problèmes CGI ne doivent - jamais être postées dans la base de données de - bogues d'Apache, à moins que vous ne soyez sûr d'avoir trouvé un - problème dans le code source d'Apache.
-Serveur Apache HTTP Version 2.3
+| Modules Apparentés | Directives Apparentées |
|---|---|
CGI (Common Gateway Interface) définit une méthode d'interaction + entre un serveur web et des programmes générateurs de contenu + externes, plus souvent appelés programmes CGI ou scripts CGI. Il + s'agit de la méthode la plus simple, et la plus + courante, pour ajouter du contenu dynamique à votre site web. Ce + document est une introduction à la configuration de CGI sur votre + serveur web Apache, et une initiation à l'écriture de programmes + CGI.
+Apache doit être configuré pour permettre l'exécution des + programmes CGI, pour que vos programmes CGI puissent fonctionner + correctement. Il existe plusieurs méthodes pour y parvenir.
+ +LoadModule correspondante n'a pas été
+ commentée dans votre httpd.conf. Une directive correcte
+ doit ressembler à ceci :
+
+
+ LoadModule cgi_module modules/mod_cgi.so
+
La directive ScriptAlias indique à Apache qu'un
+ répertoire particulier est dédié aux programmes CGI. Apache
+ considérera que tout fichier situé dans ce répertoire est un
+ programme CGI, et tentera de l'exécuter lorsque cette ressource
+ fera l'objet d'une requête client.
La directive ScriptAlias se présente comme suit
+ :
+ ScriptAlias /cgi-bin/ /usr/local/apache2/cgi-bin/
+
Cet exemple est tiré de votre fichier de configuration
+ httpd.conf par défaut, si vous avez installé Apache
+ dans son répertoire par défaut. La directive ScriptAlias est similaire à la
+ directive Alias, qui
+ définit à quel répertoire particulier doit correspondre un préfixe
+ d'URL. Alias et
+ ScriptAlias sont généralement utilisés pour
+ accéder à des répertoires situés en dehors du répertoire défini
+ par la directive DocumentRoot. La différence entre
+ Alias et ScriptAlias
+ réside dans le fait que ScriptAlias indique
+ en plus que tout ce qui se trouve sous le préfixe d'URL doit être
+ considéré comme un programme CGI. Ainsi, l'exemple ci-dessus
+ indique à Apache que toute requête pour une ressource commençant
+ par /cgi-bin/ doit être servie depuis le répertoire
+ /usr/local/apache2/cgi-bin/, et doit être traitée en
+ tant que programme CGI.
Par exemple, si une requête pour l'URL
+ http://www.example.com/cgi-bin/test.pl est
+ effectuée, Apache tentera d'exécuter le fichier
+ /usr/local/apache2/cgi-bin/test.pl et en renverra la
+ sortie. Bien entendu, le fichier doit exister, être exécutable, et
+ retourner sa sortie d'une manière particulière, sinon Apache
+ renverra un message d'erreur.
Pour des raisons de sécurité, la localisation des programmes
+ CGI est souvent restreinte aux
+ répertoires définis par ScriptAlias. De cette manière, les administrateurs
+ peuvent contrôler précisément qui est autorisé à utiliser les
+ programmes CGI. Cependant, si les précautions adéquates quant à
+ la sécurité sont prises, il n'y a aucune raison pour que les
+ programmes CGI ne puissent pas être exécutés depuis d'autres
+ répertoires. Par exemple, vous pouvez autoriser les utilisateurs à
+ enregistrer des contenus web dans leurs répertoires home à l'aide
+ de la directive UserDir. S'ils veulent mettre en
+ oeuvre leurs propres programmes CGI, mais n'ont pas l'autorisation
+ d'accès au répertoire cgi-bin principal, ils devront
+ être en mesure d'exécuter ces programmes depuis un autre
+ répertoire.
L'autorisation d'exécution des programmes CGI dans un
+ répertoire arbitraire se fait en deux étapes. En premier lieu, le
+ gestionnaire cgi-script doit être activé à l'aide
+ d'une directive AddHandler ou SetHandler. En second lieu,
+ ExecCGI doit être spécifié dans la directive Options.
Vous pouvez utiliser de manière explicite la directive
+ Options dans le fichier de
+ configuration de votre serveur principal, pour indiquer que
+ l'exécution des programmes CGI est permise depuis un répertoire
+ particulier :
+ <Directory /usr/local/apache2/htdocs/un-repertoire>
+
+ Options +ExecCGI
+
+ </Directory>
+
La directive ci-dessus indique à Apache qu'il doit permettre
+ l'exécution des fichiers CGI. Vous devez aussi indiquer au serveur
+ quels fichiers sont des fichiers CGI. La directive AddHandler suivante indique au
+ serveur qu'il doit traiter tous les fichiers possédant une
+ extension cgi ou pl en tant que
+ programmes CGI :
+ AddHandler cgi-script .cgi .pl
+
Le tutoriel
+ .htaccess montre comment activer les programmes
+ CGI si vous n'avez pas accès au
+ fichier httpd.conf.
Pour permettre l'exécution en tant que programme CGI de tout
+ fichier possédant l'extension .cgi et situé dans un
+ répertoire utilisateur, vous pouvez utiliser la configuration
+ suivante :
+ <Directory /home/*/public_html>
+
+ Options +ExecCGI
+ AddHandler cgi-script .cgi
+
+ </Directory>
+
Pour indiquer un sous-répertoire cgi-bin d'un
+ répertoire utilisateur où tout fichier sera traité en tant que
+ programme CGI, vous pouvez utiliser ceci :
+ <Directory /home/*/public_html/cgi-bin>
+
+ Options ExecCGI
+ SetHandler cgi-script
+
+ </Directory>
+
Il y a deux différences principales entre la programmation + "standard" et la programmation CGI.
+ +En premier lieu, toute sortie de votre programme CGI doit être + précédée d'un en-tête MIME-type. Il s'agit d'un + en-tête HTTP qui indique au client quel type de contenu il reçoit. + La plupart du temps, il se présente comme suit :
+ +
+ Content-type: text/html
+
En second lieu, votre sortie doit être en HTML, ou tout autre + format qu'un navigateur est en mesure d'afficher. La plupart du + temps, il s'agira de HTML, mais occasionnellement, vous pouvez être + amené à écrire un programme CGI qui renvoie une image gif, ou un + autre type de contenu non-HTML.
+ +A part ces deux différences, un programme CGI ressemblera à tout + autre programme que vous pourriez être amené à écrire.
+ +L'exemple suivant est un exemple de programme CGI qui permet
+ d'afficher une ligne de caractères dans votre navigateur. Ecrivez
+ ce qui suit, enregistrez le dans un fichier nommé
+ premier.pl, et placez le dans votre répertoire
+ cgi-bin.
+ #!/usr/bin/perl
+ print "Content-type: text/html\n\n";
+ print "Bonjour tout le monde . . .";
+
Même si Perl ne vous est pas familier, vous devriez être
+ capable de comprendre le fonctionnement de ce programme. La
+ première ligne indique à Apache (ou à toute interface à partir de
+ laquelle le programme s'exécute) que ce programme peut être
+ exécuté en fournissant son fichier à l'interpréteur
+ /usr/bin/perl. La seconde ligne affiche la
+ déclaration du type de contenu considéré, suivie de deux paires
+ "Retour chariot - Nouvelle ligne". Ceci a pour effet d'insérer une
+ ligne vide après l'en-tête pour marquer la fin des en-têtes HTTP,
+ et le début du corps du document. La troisième ligne affiche la
+ chaîne de caractères "Bonjour tout le monde . . .". Et c'est tout
+ ce dont vous avez besoin.
Si vous ouvrez votre navigateur favori et lui indiquez + l'adresse
+ +
+ http://www.exemple.com/cgi-bin/premier.pl
+
ou toute autre URL correspondant à votre programme CGI, Vous
+ verrez la ligne Bonjour tout le monde . . .
+ s'afficher dans la fenêtre de votre navigateur. Ce n'est pas
+ extraordinaire, mais si vous y êtes parvenu, vous avez de bonnes
+ chances d'y parvenir pour tout autre programme plus
+ sophistiqué.
Vous devriez voir au moins une des quatre sorties suivantes dans + votre navigateur lorsque vous essayez d'accéder à votre programme + CGI depuis le web :
+ +Content-Type de manière appropriée dans votre
+ programme CGI.Souvenez-vous que le serveur ne s'exécute pas sous votre nom.
+ En d'autres termes, lorsque le serveur a démarré, il s'exécute
+ avec les droits d'un utilisateur non privilégié - en général
+ nobody, ou www - et en conséquence, il
+ aura besoin de droits supplémentaires pour pouvoir exécuter des
+ fichiers dont vous êtes le propriétaire. En général, pour qu'un
+ fichier ait des droits suffisants pour être exécutable par
+ nobody, il suffit de lui attribuer des droits
+ d'exécution pour tout le monde :
+ chmod a+x premier.pl
+
En outre, si votre programme doit pouvoir accéder en lecture + et/ou écriture à d'autres fichiers, ces derniers devront avoir les + droits appropriés.
+ + + +Lorsque vous lancez un programme depuis la ligne de commande,
+ certaines informations sont passées au shell sans que vous vous en
+ doutiez. Par exemple, la variable PATH indique au
+ shell où il doit rechercher les exécutables auxquels vous faites
+ référence.
Lorsqu'un programme s'exécute depuis le serveur web en tant que
+ programme CGI, sa variable PATH n'aura peut-être pas
+ la même valeur. Tout programme que vous invoquez dans votre
+ programme CGI ( comme par exemple sendmail) devra
+ être spécifié par son chemin complet, de façon à ce que le shell
+ puisse le trouver lorsqu'il tentera d'exécuter votre programme
+ CGI.
Un exemple typique de spécification de programme est le chemin
+ vers l'interpréteur de script (souvent perl) que l'on
+ trouve à la première ligne de votre programme CGI et qui va
+ ressembler à ceci :
+ #!/usr/bin/perl
+
Assurez-vous qu'il s'agit bien du chemin correct vers + l'interpréteur.
+ +De plus, si votre programme CGI dépend d'autres variables d'environnement, vous devrez vous + assurer qu'elles lui sont bien transmises par Apache.
+ + + +La plupart des échecs dans l'exécution d'un programme CGI + proviennent du programme lui-même. Ceci est particulièrement vrai + lorsque ce satané programme CGI se bloque, alors que vous avez + appris à ne plus commettre les deux erreurs précédentes. La + première chose à faire est de vous assurer que votre programme + s'exécute depuis la ligne de commande, avant de le tester à partir + du serveur web. Par exemple, essayez :
+ +
+ cd /usr/local/apache2/cgi-bin
+ ./premier.pl
+
(N'invoquez pas l'interpréteur perl. Le shell et
+ Apache doivent être capable de le déterminer à partir de l'information sur le chemin située sur
+ la première ligne du script.)
La première chose que vous devriez voir affichée par votre
+ programme est un ensemble d'en-têtes HTTP, comprenant entre autres
+ le Content-Type, et suivi d'une ligne vide. Si vous
+ voyez quoi que ce soit d'autre, Apache renverra l'erreur
+ Premature end of script headers si vous tentez
+ d'exécuter le programme depuis le serveur. Voir Ecriture d'un programme CGI ci-dessus pour
+ plus de détails.
Les journaux d'erreurs sont vos amis. Toute anomalie de + fonctionnement est consignée dans le journal des erreurs et c'est + ici que vous devez regarder en premier en cas de problème. Si + l'hébergeur de votre site ne vous donne pas accès au journal des + erreurs, vous avez tout intérêt à vous tourner vers quelqu'un + d'autre. Apprenez à déchiffrer les journaux d'erreurs, et vous + vous apercevrez que la plupart des problèmes seront rapidement + identifiés . . . et résolus.
+ + +Le programme suexec permet
+ d'exécuter les programmes CGI avec des droits différents selon le
+ serveur virtuel ou le répertoire utilisateur dans lequel ils
+ se situent. Suexec effectue une vérification des droits très
+ stricte, et toute anomalie détectée au cours de cette vérification
+ entraînera un echec d'exécution de votre programme CGI avec
+ affichage de l'erreur Premature end of script
+ headers.
Pour savoir si vous pouvez utiliser suexec, tapez la commande
+ apachectl -V, et regardez le chemin indiqué par
+ SUEXEC_BIN. Si au démarrage d'Apache, ce dernier
+ trouve un exécutable suexec dans ce chemin,
+ suexec sera activé.
Si vous ne maîtrisez pas le fonctionnement de suexec, il vous
+ est déconseillé de l'utiliser. Pour désactiver suexec, supprimer
+ simplement (ou renommez) l'exécutable suexec
+ pointé par SUEXEC_BIN et redémarrez le serveur. Si
+ après une lecture de suexec, vous
+ décidez quand-même de l'utiliser, tapez la commande suexec
+ -V pour voir où se situe le journal de suexec, et utilisez
+ ce dernier pour déterminer quelles règles vous violez
+ éventuellement.
Lorsque vos compétences en programmation CGI seront plus + poussées, il s'avérera intéressant pour vous de mieux comprendre ce + qui se passe en coulisse, et en particulier la manière dont le + navigateur et le serveur dialoguent entre eux. En effet, bien qu'il + soit tout à fait louable d'écrire un programme qui affiche "Bonjour + tout le monde . . .", cela ne sert pas à grand chose.
+ +Les variables d'environnement sont des valeurs qui gravitent
+ autour de vous lorsque vous utilisez votre ordinateur. Elles sont
+ très utiles, à l'instar de votre chemin par défaut (où votre
+ ordinateur va rechercher le fichier physique correspondant à la
+ commande que vous avez tapée), votre nom d'utilisateur, le type de
+ votre terminal, etc... Pour obtenir une liste complète des
+ variables d'environnement standards que vous utilisez tous les
+ jours, tapez env dans votre interpréteur
+ de commandes.
Au cours de la transaction CGI, le serveur et le navigateur + définissent aussi des variables d'environnement, de façon à ce + qu'ils puissent communiquer entre eux. Ces variables définissent + entre autre le type de navigateur (Netscape, IE, Lynx), le type de + serveur (Apache, IIS, WebSite), le nom du programme CGI en cours + d'exécution, etc...
+ +Ces variables sont à la disposition du programmeur CGI, et + elles constituent 50% de la communication client-serveur. La liste + complète des variables requises se trouve à + http://hoohoo.ncsa.uiuc.edu/cgi/env.html.
+ +Ce programme CGI basique en Perl permet d'afficher toutes les
+ variables d'environnement qui sont échangées. Deux programmes
+ similaires sont fournis avec la distribution d'Apache et situés
+ dans le répertoire cgi-bin.
+ Notez que certaines variables sont
+ obligatoires, alors que d'autres sont optionnelles, si bien que
+ vous verrez s'afficher certaines variables qui ne font pas partie
+ de la liste officielle. De plus, Apache vous propose de nombreuses
+ méthodes pour ajouter vos propres
+ variables d'environnement aux variables de base fournies par
+ défaut.
+ #!/usr/bin/perl
+ print "Content-type: text/html\n\n";
+ foreach $key (keys %ENV) {
+
+ print "$key --> $ENV{$key}<br>";
+
+ }
+
L'entrée standard (STDIN) et la sortie standard
+ (STDOUT) constituent d'autres voies de communication
+ entre le client et le serveur. Dans un contexte normal,
+ STDIN correspond au clavier, ou à un fichier fourni
+ au programme à des fins de traitement, et STDOUT à la
+ console ou à l'écran.
Lorsque vous transmettez un formulaire web à un programme CGI
+ par la méthode POST, les données de ce formulaire
+ sont transcrites dans un format spécial et transmises à votre
+ programme CGI via STDIN. Le programme peut alors les
+ traiter comme si elles provenaient du clavier ou d'un
+ fichier.
Ce "format spécial" est très simple. Un nom de champ et sa + valeur sont reliés entre eux par un signe "égal" (=), et chacune + de ces paires nom champ/valeur est séparée de la suivante par un + "et" commercial (&). Les caractères + spéciaux comme les espaces, les "et" commerciaux, et les signes + "égal" sont convertis en leur équivalent hexadécimal pour éviter + qu'ils ne gâchent le travail. La chaîne contenant les données doit + ressembler à ceci :
+ +
+ name=Rich%20Bowen&city=Lexington&state=KY&sidekick=Squirrel%20Monkey
+
Vous verrez aussi parfois une chaîne de ce type accolée à une
+ URL. Dans ce cas, le serveur enregistre cette chaîne dans la
+ variable d'environnement appelée QUERY_STRING. On a
+ alors affaire à une requête de type GET. Votre
+ formulaire HTML indique laquelle des méthodes GET ou
+ POST est utilisée pour transmettre les données, en
+ définissant l'attribut METHOD au niveau de la balise
+ FORM.
Votre programme est ensuite chargé d'extraire les informations + utiles de cette chaîne. Heureusement, des bibliothèques et des + modules sont à votre disposition pour vous aider à traiter ces + données, et à gérer les différents aspects de votre programme + CGI.
+ +Pour écrire un programme CGI, il vous est conseillé d'utiliser + une bibliothèque de code, ou un module, qui effectueront une grande + partie du travail de base pour vous. Ceci vous permettra de diminuer + le nombre d'erreurs et d'accélérer le développement.
+ +Si vous écrivez des programmes CGI en Perl, des modules sont à
+ votre disposition à CPAN. A ce
+ sujet, le module le plus populaire est CGI.pm. Vous
+ pouvez aussi essayer CGI::Lite, qui implémente les
+ fonctionnalités strictement nécessaires, mais suffisantes pour
+ la majorité des programmes.
Si vous écrivez des programmes CGI en C, vous disposez de
+ nombreuses options. L'une d'elles est la bibliothèque
+ CGIC de http://www.boutell.com/cgic/.
Il existe un grand nombre de ressources CGI sur le web. Vous + pouvez discuter de problèmes CGI avec d'autres utilisateurs dans le + groupe Usenet + comp.infosystems.www.authoring.cgi. En outre, la liste de + diffusion de la Guilde des Ecrivains HTML est une source + intarissable de réponses à vos questions. Vous en saurez plus en + vous rendant à http://www.hwg.org/lists/hwg-servers/.
+ +Et bien entendu, vous devez lire la spécification CGI, qui + présente tous les détails en rapport avec les opérations des + programmes CGI. La version originale se trouve au NCSA, et + dans la RFC IETF actuelle Common Gateway + Interface RFC.
+ +Lorsque vous postez une question à propos d'un problème CGI que + vous rencontrez, que ce soit dans une liste de diffusion ou dans un + newsgroup, faites en sorte de fournir suffisamment d'informations + sur le problème rencontré, ce que vous attendiez exactement, et en + quoi ce qui se produit est réellement différent de ce que vous + attendiez, quel serveur vous utilisez, en quel langage votre + programme CGI a été écrit, et, si possible, son code source. Ceci + permettra une résolution plus aisée de votre problème.
+ +Notez que les questions à propos de problèmes CGI ne doivent + jamais être postées dans la base de données de + bogues d'Apache, à moins que vous ne soyez sûr d'avoir trouvé un + problème dans le code source d'Apache.
+Serveur Apache HTTP Version 2.3
-Les fichiers .htaccess fournissent une méthode pour
-modifier la configuration du serveur au niveau de chaque répertoire.
Fichiers .htaccess Que sont ce fichiers, comment les utiliser ? Quand doit-on (ne doit-on pas) utiliser
- les fichiers .htaccess ? Comment sont appliquées les directives ? Exemple d'authentification Exemple d'Inclusion Côté Serveur (Server Side
-Includes - SSI) Exemple de CGI Résolution des problèmes| Modules Apparentés | Directives Apparentées |
|---|---|
Les fichiers .htaccess (ou "fichiers de
- configuration distribués") fournissent une méthode pour modifier la
- configuration du serveur au niveau d'un répertoire. Un fichier,
- contenant une ou plusieurs directives de configuration, est placé
- dans un répertoire de documents particulier, et ses directives
- s'appliquent à ce répertoire et à tous ses sous-répertoires.
Si vous voulez donner un autre nom à votre fichier
- .htaccess, vous pouvez le faire en utilisant la
- directive AccessFileName. Par
- exemple, si vous préférez nommer votre fichier
- .config, vous pouvez mettre ceci dans le fichier de
- configuration de votre serveur :
- AccessFileName .config
-
En général, les fichiers .htaccess utilisent la même
- syntaxe que les fichiers de
- configuration principaux. Ce que vous pouvez mettre dans ces
- fichier est déterminé par la directive AllowOverride. Cette directive spécifie,
- sous forme de catégories, quelles directives seront traitées si
- elles se trouvent dans un fichier .htaccess. Si une
- directive est permise dans un fichier .htaccess file,
- la documentation de cette directive contiendra une section Override,
- spécifiant quelle valeur doit prendre AllowOverride pour que cette directive
- soit traitée.
Par exemple, si vous regardez la documentation de la directive
- AddDefaultCharset, vous verrez
- que cette dernière est permise dans les fichiers
- .htaccess (Voir la ligne de contexte dans le résumé de
- la directive). La ligne Override indique
- FileInfo. Vous devez donc avoir au moins
- AllowOverride FileInfo pour que cette directive soit
- traitée dans les fichiers .htaccess.
| Contexte : | -configuration du serveur, serveur virtuel, directory, .htaccess | -
| Override: | -FileInfo | -
Si vous n'êtes pas sûr qu'une directive particulière soit permise
- dans un fichier .htaccess, lisez la documentation de
- cette directive, et consultez la ligne de contexte pour
- ".htaccess".
En principe, vous ne devriez utiliser les fichiers
- .htaccess que si vous n'avez pas accès au fichier de
- configuration du serveur principal. Par exemple, la fausse idée
- selon laquelle l'authentification de l'utilisateur devrait toujours
- être faite dans les fichiers .htaccess est très
- répandue. Ceci est tout simplement faux. Vous pouvez configurer
- l'authentification des utilisateurs au niveau de la configuration du
- serveur principal, et c'est en fait cette méthode qui doit être
- privilégiée.
Les fichiers .htaccess ne devraient être utilisés
- que dans le cas où les fournisseurs de contenu ont besoin de
- modifier la configuration du serveur au niveau d'un répertoire, mais
- ne possèdent pas l'accès root sur le système du serveur. Si
- l'administrateur du serveur ne souhaite pas effectuer des
- modifications de configuration incessantes, il peut être intéressant
- de permettre aux utilisateurs isolés d'effectuer eux-mêmes ces
- modifications par le biais de fichiers .htaccess. Ceci
- est particulièrement vrai dans le cas où le fournisseur d'accès à
- Internet héberge de nombreux sites d'utilisateurs sur un seul
- serveur, et souhaite que ces utilisateurs puissent modifier
- eux-mêmes leurs configurations.
Cependant et d'une manière générale, il vaut mieux éviter
- d'utiliser les fichiers .htaccess. Tout élément de
- configuration que vous pourriez vouloir mettre dans un fichier
- .htaccess, peut aussi être mis, et avec la même
- efficacité, dans une section <Directory> du fichier de configuration de
- votre serveur principal.
Il y a deux raisons principales d'éviter l'utilisation des
- fichiers .htaccess.
La première est liée aux performances. Lorsque la directive
- AllowOverride est définie de
- façon à autoriser l'utilisation des fichiers .htaccess,
- Apache va rechercher leur présence dans chaque répertoire. Ainsi,
- permettre l'utilisation des fichiers .htaccess est déjà
- en soi une cause de dégradation des performances, que vous utilisiez
- effectivement ces fichiers ou non ! De plus, le fichier
- .htaccess est chargé en mémoire chaque fois qu'un
- document fait l'objet d'une requête.
Notez aussi qu'Apache doit rechercher les fichiers
- .htaccess dans tous les répertoires de niveau
- supérieur, afin de rassembler toutes les directives qui s'appliquent
- au répertoire courant (Voir la section comment sont
- appliquées les directives). Ainsi, si un fichier fait l'objet
- d'une requête à partir d'un répertoire
- /www/htdocs/exemple, Apache doit rechercher les
- fichiers suivants :
- /.htaccess
- /www/.htaccess
- /www/htdocs/.htaccess
- /www/htdocs/exemple/.htaccess
-
En conséquence, chaque accès à un fichier de ce répertoire
- nécessite 4 accès au système de fichiers supplémentaires pour
- rechercher des fichiers .htaccess, même si
- aucun de ces fichiers n'est présent. Notez que cet exemple ne peut
- se produire que si les fichiers .htaccess ont été
- autorisés pour le répertoire /, ce qui est rarement le
- cas.
La seconde raison d'éviter l'utilisation des fichiers
- .htaccess est liée à la sécurité. Si vous permettez aux
- utilisateurs de modifier la configuration du serveur, il peut en
- résulter des conséquences sur lesquelles vous n'aurez aucun
- contrôle. Réfléchissez bien avant de donner ce privilège à vos
- utilisateurs. Notez aussi que ne pas donner aux utilisateurs les
- privilèges dont ils ont besoin va entraîner une augmentation des
- demandes de support technique. Assurez-vous d'avoir informé
- clairement vos utilisateurs du niveau de privilèges que vous leur
- avez attribué. Indiquer exactement comment vous avez défini la
- directive AllowOverride et
- diriger les utilisateurs vers la documentation correspondante vous
- évitera bien des confusions ultérieures.
Notez que mettre un fichier .htaccess contenant une
- directive dans un répertoire /www/htdocs/exemple
- revient exactement au même que mettre la même directive dans une
- section Directory <Directory /www/htdocs/exemple>
- du fichier de configuration de votre serveur principal :
Fichier .htaccess dans
- /www/htdocs/exemple :
/www/htdocs/exemple
- AddType text/exemple .exm
-
httpd.conf
- <Directory /www/htdocs/exemple>
-
- AddType text/exemple .exm
-
- </Directory>
-
Cependant, la perte de performances sera moindre si vous
- définissez cette directive dans la configuration de
- votre serveur principal, car cette dernière ne sera chargée qu'une
- seule fois au moment du démarrage du serveur, alors qu'elle le sera
- à chaque accès dans le cas d'un fichier .htaccess.
L'utilisation des fichiers .htaccess peut être
- entièrement désactivée en définissant la directive AllowOverride à none :
- AllowOverride None
-
Les directives de configuration situées dans un fichier
- .htaccess s'appliquent au répertoire dans lequel ce
- fichier .htaccess se trouve, ainsi qu'à tous ses
- sous-répertoires. Cependant, il est important de garder à l'esprit
- qu'il peut y avoir des fichiers .htaccess dans les
- répertoires de niveau supérieur. Les directives sont appliquées
- selon l'ordre dans lequel elles sont rencontrées. Ainsi, les
- directives d'un fichier .htaccess situé dans un
- répertoire particulier peuvent écraser les directives se trouvant
- dans des fichiers .htaccess situés à un niveau
- supérieur dans l'arborescence des répertoires. Et ces dernières
- peuvent elles-mêmes avoir écrasé des directives d'un fichier
- .htaccess situé à un niveau encore plus haut, ou dans
- le fichier de configuration du serveur principal.
Exemple :
- -Dans le répertoire /www/htdocs/exemple1 se trouve un
- fichier .htaccess contenant ce qui suit :
- Options +ExecCGI
-
Note : "AllowOverride Options" doit être présent
- pour permettre l'utilisation de la directive "Options" dans les fichiers
- .htaccess.
Dans le répertoire /www/htdocs/exemple1/exemple2 se
- trouve un fichier .htaccess contenant ce qui suit
- :
- Options Includes
-
Ainsi, à cause de ce second fichier .htaccess du
- répertoire /www/htdocs/exemple1/exemple2, l'exécution
- des CGI est interdite, car la dernière définition d'options
- Options Includes écrase toute autre définition
- d'options d'un fichier .htaccess situé dans un
- répertoire de niveau supérieur.
Comme indiqué dans la documentation sur les Sections de configuration, les fichiers
- .htaccess peuvent écraser les directives des sections
- <Directory> pour
- le répertoire correspondant, mais peuvent eux-mêmes être écrasés
- par d'autres types de sections des fichiers de la
- configuration principale. Cette possibilité peut s'avérer utile pour
- forcer certaines configurations, même en cas de présence de l'option
- libérale AllowOverride. Par
- exemple, pour interdire l'exécution de scripts en autorisant la
- définition de toute autre option dans les fichiers
- .htaccess, vous pouvez utiliser :
-<Directory />
-
-Allowoverride All
-
-</Directory>
-
-<Location />
-
-Options +IncludesNoExec -ExecCGI
-
-</Location>
-
Si vous accédez directement à ce point du document pour apprendre
- à effectuer une authentification, il est important de noter ceci. Il
- existe une fausse idée selon laquelle il serait nécessaire
- d'utiliser les fichiers .htaccess pour implémenter
- l'authentification par mot de passe. Ceci est tout simplement faux.
- Pour y parvenir, il est préférable de mettre les directives
- d'authentification dans une section <Directory> du fichier de configuration de
- votre serveur principal, et les fichiers .htaccess ne
- devraient être utilisés que dans le cas où vous n'avez pas accès au
- fichier de configuration du serveur principal. Voir ci-dessus pour savoir dans quels cas vous devez ou
- ne devez pas utiliser les fichiers .htaccess.
Ceci étant dit, si vous pensez que vous devez quand-même utiliser
- un fichier .htaccess, vous pouvez utiliser la
- configuration suivante :
Contenu du fichier .htaccess :
- AuthType Basic
- AuthName "Password Required"
- AuthUserFile /www/passwords/password.file
- AuthGroupFile /www/passwords/group.file
- Require Group admins
-
Notez que AllowOverride AuthConfig doit être présent
- pour que ces directives produisent leur effet.
Vous pouvez vous référer au tutoriel sur - l'authentification pour une description plus détaillée de - l'authentification et de l'autorisation.
-Les fichiers .htaccess sont aussi couramment
- utilisés pour activer les SSI pour un répertoire particulier. Pour y
- parvenir, on utilise les directives de configuration suivantes,
- placées dans un fichier .htaccess enregistré dans le
- répertoire considéré :
- Options +Includes
- AddType text/html shtml
- AddHandler server-parsed shtml
-
Notez que AllowOverride Options et AllowOverride
- FileInfo doivent être tous les deux présents pour que ces
- directives puissent produire leur effet.
Vous pouvez vous référer au tutoriel SSI - pour une description plus détaillée des SSI.
-En fin de compte, vous avez décidé d'utiliser un fichier
- .htaccess pour permettre l'exécution des programmes CGI
- dans un répertoire particulier. Pour y parvenir, vous pouvez
- utiliser la configuration suivante :
- Options +ExecCGI
- AddHandler cgi-script cgi pl
-
Alternativement, si vous souhaitez que tous les fichiers d'un - répertoire donné soient considérés comme des programmes CGI, vous - pouvez utiliser la configuration suivante :
- -
- Options +ExecCGI
- SetHandler cgi-script
-
Notez que AllowOverride Options et AllowOverride
- FileInfo doivent être tous les deux présents pour que ces
- directives puissent produire leur effet.
Vous pouvez vous référer au tutoriel CGI - pour une description plus détaillée de la configuration et de la - proprammation CGI.
- -De nombreuses raisons peuvent être à l'origine du fait que
- les directives que vous avez mises dans un fichier
- .htaccess ne produisent pas l'effet désiré.
Le plus souvent, le problème vient du fait que la définition de
- la directive AllowOverride
- ne permet pas l'activation des directives de votre fichier
- .htaccess. Vérifiez si une directive
- AllowOverride None n'affecte pas le répertoire où se
- trouve votre fichier. Un bon test consiste à mettre des directives
- dont la syntaxe est erronée dans votre ficher .htaccess
- et de redémarrer le serveur. Si aucune erreur n'est générée par le
- serveur, il est pratiquement certain qu'une directive
- AllowOverride None affecte votre répertoire.
Par contre, si vous obtenez des erreurs de serveur lorsque vous
- tentez d'accéder à des documents, consultez votre journal des
- erreurs d'Apache. Il vous indiquera probablement que la directive
- utilisée dans votre fichier .htaccess n'est pas
- permise.
- [Sat Aug 09 16:19:20 2008] [alert] [client 192.168.200.51] /var/www/html/.htaccess: RewriteLog not allowed here
-
Cela signifie soit que vous utilisez une directive qui n'est
- jamais permise dans les fichiers .htaccess, soit
- que vous n'avez tout simplement pas défini la directive
- AllowOverride à un niveau
- suffisant pour la directive que vous utilisez. Consultez la
- documentation de cette directive pour déterminer quel cas
- s'applique.
Le journal des erreurs peut aussi vous signaler une erreur de - syntaxe dans l'usage de la directive elle-même.
- -
- [Sat Aug 09 16:22:34 2008] [alert] [client 192.168.200.51] /var/www/html/.htaccess: RewriteCond: bad flag delimiters
-
Dans ce cas, le message d'erreur sera spécifique à l'erreur - de syntaxe que vous avez commise.
-Serveur Apache HTTP Version 2.3
+Les fichiers .htaccess fournissent une méthode pour
+modifier la configuration du serveur au niveau de chaque répertoire.
Fichiers .htaccess Que sont ce fichiers, comment les utiliser ? Quand doit-on (ne doit-on pas) utiliser
+ les fichiers .htaccess ? Comment sont appliquées les directives ? Exemple d'authentification Exemple d'Inclusion Côté Serveur (Server Side
+Includes - SSI) Exemple de CGI Résolution des problèmes| Modules Apparentés | Directives Apparentées |
|---|---|
Les fichiers .htaccess (ou "fichiers de
+ configuration distribués") fournissent une méthode pour modifier la
+ configuration du serveur au niveau d'un répertoire. Un fichier,
+ contenant une ou plusieurs directives de configuration, est placé
+ dans un répertoire de documents particulier, et ses directives
+ s'appliquent à ce répertoire et à tous ses sous-répertoires.
Si vous voulez donner un autre nom à votre fichier
+ .htaccess, vous pouvez le faire en utilisant la
+ directive AccessFileName. Par
+ exemple, si vous préférez nommer votre fichier
+ .config, vous pouvez mettre ceci dans le fichier de
+ configuration de votre serveur :
+ AccessFileName .config
+
En général, les fichiers .htaccess utilisent la même
+ syntaxe que les fichiers de
+ configuration principaux. Ce que vous pouvez mettre dans ces
+ fichier est déterminé par la directive AllowOverride. Cette directive spécifie,
+ sous forme de catégories, quelles directives seront traitées si
+ elles se trouvent dans un fichier .htaccess. Si une
+ directive est permise dans un fichier .htaccess file,
+ la documentation de cette directive contiendra une section Override,
+ spécifiant quelle valeur doit prendre AllowOverride pour que cette directive
+ soit traitée.
Par exemple, si vous regardez la documentation de la directive
+ AddDefaultCharset, vous verrez
+ que cette dernière est permise dans les fichiers
+ .htaccess (Voir la ligne de contexte dans le résumé de
+ la directive). La ligne Override indique
+ FileInfo. Vous devez donc avoir au moins
+ AllowOverride FileInfo pour que cette directive soit
+ traitée dans les fichiers .htaccess.
| Contexte : | +configuration du serveur, serveur virtuel, directory, .htaccess | +
| Override: | +FileInfo | +
Si vous n'êtes pas sûr qu'une directive particulière soit permise
+ dans un fichier .htaccess, lisez la documentation de
+ cette directive, et consultez la ligne de contexte pour
+ ".htaccess".
En principe, vous ne devriez utiliser les fichiers
+ .htaccess que si vous n'avez pas accès au fichier de
+ configuration du serveur principal. Par exemple, la fausse idée
+ selon laquelle l'authentification de l'utilisateur devrait toujours
+ être faite dans les fichiers .htaccess est très
+ répandue. Ceci est tout simplement faux. Vous pouvez configurer
+ l'authentification des utilisateurs au niveau de la configuration du
+ serveur principal, et c'est en fait cette méthode qui doit être
+ privilégiée.
Les fichiers .htaccess ne devraient être utilisés
+ que dans le cas où les fournisseurs de contenu ont besoin de
+ modifier la configuration du serveur au niveau d'un répertoire, mais
+ ne possèdent pas l'accès root sur le système du serveur. Si
+ l'administrateur du serveur ne souhaite pas effectuer des
+ modifications de configuration incessantes, il peut être intéressant
+ de permettre aux utilisateurs isolés d'effectuer eux-mêmes ces
+ modifications par le biais de fichiers .htaccess. Ceci
+ est particulièrement vrai dans le cas où le fournisseur d'accès à
+ Internet héberge de nombreux sites d'utilisateurs sur un seul
+ serveur, et souhaite que ces utilisateurs puissent modifier
+ eux-mêmes leurs configurations.
Cependant et d'une manière générale, il vaut mieux éviter
+ d'utiliser les fichiers .htaccess. Tout élément de
+ configuration que vous pourriez vouloir mettre dans un fichier
+ .htaccess, peut aussi être mis, et avec la même
+ efficacité, dans une section <Directory> du fichier de configuration de
+ votre serveur principal.
Il y a deux raisons principales d'éviter l'utilisation des
+ fichiers .htaccess.
La première est liée aux performances. Lorsque la directive
+ AllowOverride est définie de
+ façon à autoriser l'utilisation des fichiers .htaccess,
+ Apache va rechercher leur présence dans chaque répertoire. Ainsi,
+ permettre l'utilisation des fichiers .htaccess est déjà
+ en soi une cause de dégradation des performances, que vous utilisiez
+ effectivement ces fichiers ou non ! De plus, le fichier
+ .htaccess est chargé en mémoire chaque fois qu'un
+ document fait l'objet d'une requête.
Notez aussi qu'Apache doit rechercher les fichiers
+ .htaccess dans tous les répertoires de niveau
+ supérieur, afin de rassembler toutes les directives qui s'appliquent
+ au répertoire courant (Voir la section comment sont
+ appliquées les directives). Ainsi, si un fichier fait l'objet
+ d'une requête à partir d'un répertoire
+ /www/htdocs/exemple, Apache doit rechercher les
+ fichiers suivants :
+ /.htaccess
+ /www/.htaccess
+ /www/htdocs/.htaccess
+ /www/htdocs/exemple/.htaccess
+
En conséquence, chaque accès à un fichier de ce répertoire
+ nécessite 4 accès au système de fichiers supplémentaires pour
+ rechercher des fichiers .htaccess, même si
+ aucun de ces fichiers n'est présent. Notez que cet exemple ne peut
+ se produire que si les fichiers .htaccess ont été
+ autorisés pour le répertoire /, ce qui est rarement le
+ cas.
La seconde raison d'éviter l'utilisation des fichiers
+ .htaccess est liée à la sécurité. Si vous permettez aux
+ utilisateurs de modifier la configuration du serveur, il peut en
+ résulter des conséquences sur lesquelles vous n'aurez aucun
+ contrôle. Réfléchissez bien avant de donner ce privilège à vos
+ utilisateurs. Notez aussi que ne pas donner aux utilisateurs les
+ privilèges dont ils ont besoin va entraîner une augmentation des
+ demandes de support technique. Assurez-vous d'avoir informé
+ clairement vos utilisateurs du niveau de privilèges que vous leur
+ avez attribué. Indiquer exactement comment vous avez défini la
+ directive AllowOverride et
+ diriger les utilisateurs vers la documentation correspondante vous
+ évitera bien des confusions ultérieures.
Notez que mettre un fichier .htaccess contenant une
+ directive dans un répertoire /www/htdocs/exemple
+ revient exactement au même que mettre la même directive dans une
+ section Directory <Directory /www/htdocs/exemple>
+ du fichier de configuration de votre serveur principal :
Fichier .htaccess dans
+ /www/htdocs/exemple :
/www/htdocs/exemple
+ AddType text/exemple .exm
+
httpd.conf
+ <Directory /www/htdocs/exemple>
+
+ AddType text/exemple .exm
+
+ </Directory>
+
Cependant, la perte de performances sera moindre si vous
+ définissez cette directive dans la configuration de
+ votre serveur principal, car cette dernière ne sera chargée qu'une
+ seule fois au moment du démarrage du serveur, alors qu'elle le sera
+ à chaque accès dans le cas d'un fichier .htaccess.
L'utilisation des fichiers .htaccess peut être
+ entièrement désactivée en définissant la directive AllowOverride à none :
+ AllowOverride None
+
Les directives de configuration situées dans un fichier
+ .htaccess s'appliquent au répertoire dans lequel ce
+ fichier .htaccess se trouve, ainsi qu'à tous ses
+ sous-répertoires. Cependant, il est important de garder à l'esprit
+ qu'il peut y avoir des fichiers .htaccess dans les
+ répertoires de niveau supérieur. Les directives sont appliquées
+ selon l'ordre dans lequel elles sont rencontrées. Ainsi, les
+ directives d'un fichier .htaccess situé dans un
+ répertoire particulier peuvent écraser les directives se trouvant
+ dans des fichiers .htaccess situés à un niveau
+ supérieur dans l'arborescence des répertoires. Et ces dernières
+ peuvent elles-mêmes avoir écrasé des directives d'un fichier
+ .htaccess situé à un niveau encore plus haut, ou dans
+ le fichier de configuration du serveur principal.
Exemple :
+ +Dans le répertoire /www/htdocs/exemple1 se trouve un
+ fichier .htaccess contenant ce qui suit :
+ Options +ExecCGI
+
Note : "AllowOverride Options" doit être présent
+ pour permettre l'utilisation de la directive "Options" dans les fichiers
+ .htaccess.
Dans le répertoire /www/htdocs/exemple1/exemple2 se
+ trouve un fichier .htaccess contenant ce qui suit
+ :
+ Options Includes
+
Ainsi, à cause de ce second fichier .htaccess du
+ répertoire /www/htdocs/exemple1/exemple2, l'exécution
+ des CGI est interdite, car la dernière définition d'options
+ Options Includes écrase toute autre définition
+ d'options d'un fichier .htaccess situé dans un
+ répertoire de niveau supérieur.
Comme indiqué dans la documentation sur les Sections de configuration, les fichiers
+ .htaccess peuvent écraser les directives des sections
+ <Directory> pour
+ le répertoire correspondant, mais peuvent eux-mêmes être écrasés
+ par d'autres types de sections des fichiers de la
+ configuration principale. Cette possibilité peut s'avérer utile pour
+ forcer certaines configurations, même en cas de présence de l'option
+ libérale AllowOverride. Par
+ exemple, pour interdire l'exécution de scripts en autorisant la
+ définition de toute autre option dans les fichiers
+ .htaccess, vous pouvez utiliser :
+<Directory />
+
+Allowoverride All
+
+</Directory>
+
+<Location />
+
+Options +IncludesNoExec -ExecCGI
+
+</Location>
+
Si vous accédez directement à ce point du document pour apprendre
+ à effectuer une authentification, il est important de noter ceci. Il
+ existe une fausse idée selon laquelle il serait nécessaire
+ d'utiliser les fichiers .htaccess pour implémenter
+ l'authentification par mot de passe. Ceci est tout simplement faux.
+ Pour y parvenir, il est préférable de mettre les directives
+ d'authentification dans une section <Directory> du fichier de configuration de
+ votre serveur principal, et les fichiers .htaccess ne
+ devraient être utilisés que dans le cas où vous n'avez pas accès au
+ fichier de configuration du serveur principal. Voir ci-dessus pour savoir dans quels cas vous devez ou
+ ne devez pas utiliser les fichiers .htaccess.
Ceci étant dit, si vous pensez que vous devez quand-même utiliser
+ un fichier .htaccess, vous pouvez utiliser la
+ configuration suivante :
Contenu du fichier .htaccess :
+ AuthType Basic
+ AuthName "Password Required"
+ AuthUserFile /www/passwords/password.file
+ AuthGroupFile /www/passwords/group.file
+ Require Group admins
+
Notez que AllowOverride AuthConfig doit être présent
+ pour que ces directives produisent leur effet.
Vous pouvez vous référer au tutoriel sur + l'authentification pour une description plus détaillée de + l'authentification et de l'autorisation.
+Les fichiers .htaccess sont aussi couramment
+ utilisés pour activer les SSI pour un répertoire particulier. Pour y
+ parvenir, on utilise les directives de configuration suivantes,
+ placées dans un fichier .htaccess enregistré dans le
+ répertoire considéré :
+ Options +Includes
+ AddType text/html shtml
+ AddHandler server-parsed shtml
+
Notez que AllowOverride Options et AllowOverride
+ FileInfo doivent être tous les deux présents pour que ces
+ directives puissent produire leur effet.
Vous pouvez vous référer au tutoriel SSI + pour une description plus détaillée des SSI.
+En fin de compte, vous avez décidé d'utiliser un fichier
+ .htaccess pour permettre l'exécution des programmes CGI
+ dans un répertoire particulier. Pour y parvenir, vous pouvez
+ utiliser la configuration suivante :
+ Options +ExecCGI
+ AddHandler cgi-script cgi pl
+
Alternativement, si vous souhaitez que tous les fichiers d'un + répertoire donné soient considérés comme des programmes CGI, vous + pouvez utiliser la configuration suivante :
+ +
+ Options +ExecCGI
+ SetHandler cgi-script
+
Notez que AllowOverride Options et AllowOverride
+ FileInfo doivent être tous les deux présents pour que ces
+ directives puissent produire leur effet.
Vous pouvez vous référer au tutoriel CGI + pour une description plus détaillée de la configuration et de la + proprammation CGI.
+ +De nombreuses raisons peuvent être à l'origine du fait que
+ les directives que vous avez mises dans un fichier
+ .htaccess ne produisent pas l'effet désiré.
Le plus souvent, le problème vient du fait que la définition de
+ la directive AllowOverride
+ ne permet pas l'activation des directives de votre fichier
+ .htaccess. Vérifiez si une directive
+ AllowOverride None n'affecte pas le répertoire où se
+ trouve votre fichier. Un bon test consiste à mettre des directives
+ dont la syntaxe est erronée dans votre ficher .htaccess
+ et de redémarrer le serveur. Si aucune erreur n'est générée par le
+ serveur, il est pratiquement certain qu'une directive
+ AllowOverride None affecte votre répertoire.
Par contre, si vous obtenez des erreurs de serveur lorsque vous
+ tentez d'accéder à des documents, consultez votre journal des
+ erreurs d'Apache. Il vous indiquera probablement que la directive
+ utilisée dans votre fichier .htaccess n'est pas
+ permise.
+ [Sat Aug 09 16:19:20 2008] [alert] [client 192.168.200.51] /var/www/html/.htaccess: RewriteLog not allowed here
+
Cela signifie soit que vous utilisez une directive qui n'est
+ jamais permise dans les fichiers .htaccess, soit
+ que vous n'avez tout simplement pas défini la directive
+ AllowOverride à un niveau
+ suffisant pour la directive que vous utilisez. Consultez la
+ documentation de cette directive pour déterminer quel cas
+ s'applique.
Le journal des erreurs peut aussi vous signaler une erreur de + syntaxe dans l'usage de la directive elle-même.
+ +
+ [Sat Aug 09 16:22:34 2008] [alert] [client 192.168.200.51] /var/www/html/.htaccess: RewriteCond: bad flag delimiters
+
Dans ce cas, le message d'erreur sera spécifique à l'erreur + de syntaxe que vous avez commise.
+Serveur Apache HTTP Version 2.3
-Sur les systèmes multi-utilisateurs, on peut permettre à chaque
-utilisateur d'avoir un site web dans son répertoire home à l'aide de la
-directive UserDir. Les
-visiteurs de l'URL http://exemple.com/~nom_utilisateur/
-recevront un contenu situé dans le répertoire home de l'utilisateur
-"nom_utilisateur", et dans le sous-répertoire spécifié par
-la directive UserDir.
Notez que par défaut, l'accès à ces répertoires n'est
-pas permis. Vous pouvez en permettre l'accès à l'aide
-de la directive UserDir en
-décommentant la ligne
- #Include conf/extra/httpd-userdir.conf
-
dans le fichier de configuration par défaut, et en adaptant le
- fichier httpd-userdir.conf selon vos besoins, ou en
- incluant les directives appropriées dans une section
- Directory du fichier de configuration principal.
Répertoires web utilisateurs Définition du chemin des fichiers avec UserDir Redirection vers des URLs externes Définition de la liste des utilisateurs autorisés à utiliser
- cette fonctionnalité Définition d'un répertoire CGI pour chaque utilisateur Permettre aux utilisateurs de modifier la
- configuration| Modules Apparentés | Directives Apparentées |
|---|---|
La directive UserDir
- permet de spécifier un répertoire à partir duquel le contenu de
- l'utilisateur pourra être chargé. Elle peut revêtir plusieurs
- formes.
Si le chemin spécifié ne commence pas par un slash, il sera - interprété comme chemin relatif au répertoire home de l'utilisateur - considéré. Par exemple, avec cette configuration :
- -
- UserDir public_html
-
l'URL http://exemple.com/~rbowen/fichier.html
- correspondra au chemin fichier
- /home/rbowen/public_html/fichier.html
Si le chemin spécifié commence par un slash, le chemin du fichier - sera construit en utilisant ce chemin, suivi du nom de l'utilisateur - considéré. Par exemple, avec cette configuration :
- -
- UserDir /var/html
-
l'URL http://exemple.com/~rbowen/fichier.html
- correspondra au chemin fichier
- /var/html/rbowen/fichier.html
Si le chemin spécifié contient un astérisque (*), ce dernier sera - remplacé par le nom de l'utilisateur dans le chemin du fichier - correspondant. Par exemple, avec cette configuration :
- -
- UserDir /var/www/*/docs
-
l'URL http://exemple.com/~rbowen/fichier.html
- correspondra au chemin fichier
- /var/www/rbowen/docs/fichier.html
On peut aussi définir plusieurs répertoires ou chemins de - répertoires.
- -
- UserDir public_html /var/html
-
Avec l'URL http://exemple.com/~rbowen/fichier.html,
- Apache va rechercher ~rbowen. S'il ne le trouve pas,
- Apache va rechercher rbowen dans
- /var/html. S'il le trouve, l'URL ci-dessus correspondra
- au chemin fichier /var/html/rbowen/file.html
On peut utiliser la directive UserDir pour rediriger les requêtes
- relatives aux répertoires utilisateurs vers des URLs externes.
- UserDir http://exemple.org/users/*/
-
L'exemple ci-dessus va rediriger une requête pour
- http://exemple.com/~bob/abc.html vers
- http://exemple.org/users/bob/abc.html.
En suivant la syntaxe décrite dans la documentation de UserDir, - vous pouvez définir quels utilisateurs sont autorisés à utiliser - cette fonctionnalité :
- -
- UserDir enabled
- UserDir disabled root jro fish
-
La configuration ci-dessus va autoriser l'utilisation de la
- fonctionnalité pour tous les utilisateurs, à l'exception de ceux
- listés à la suite de l'argument disabled. De même, vous
- pouvez interdire l'utilisation de la fonctionnalité à tous les
- utilisateurs sauf certains d'entre eux en utilisant une
- configuration du style :
- UserDir disabled
- UserDir enabled rbowen krietz
-
Vous trouverez d'autres exemples dans la documentation de
- UserDir.
Afin de réserver un répertoire cgi-bin pour chaque utilisateur,
- vous pouvez utiliser une section <Directory> pour activer CGI dans un
- sous-répertoire particulier d'un répertoire home utilisateur.
- <Directory /home/*/public_html/cgi-bin/>
- Options ExecCGI
- SetHandler cgi-script
- </Directory>
-
Avec la configuration ci-dessus, et en supposant que
- UserDir est défini à public_html, un
- programme CGI exemple.cgi pourra être chargé depuis ce
- répertoire en passant par l'URL :
- http://exemple.com/~rbowen/cgi-bin/exemple.cgi
-
Si vous voulez que vos utilisateurs puissent modifier la
- configuration du serveur pour ce qui concerne leur espace web, ils
- devront utiliser des fichiers .htaccess pour effectuer
- ces modifications. Assurez-vous d'avoir défini la directive
- AllowOverride à une valeur
- appropriée pour les directives dont vous voulez permettre la
- modification aux utilisateurs. Voir le tutoriel .htaccess pour plus de détails sur
- la manière dont tout ceci fonctionne.
Serveur Apache HTTP Version 2.3
+Sur les systèmes multi-utilisateurs, on peut permettre à chaque
+utilisateur d'avoir un site web dans son répertoire home à l'aide de la
+directive UserDir. Les
+visiteurs de l'URL http://exemple.com/~nom_utilisateur/
+recevront un contenu situé dans le répertoire home de l'utilisateur
+"nom_utilisateur", et dans le sous-répertoire spécifié par
+la directive UserDir.
Notez que par défaut, l'accès à ces répertoires n'est
+pas permis. Vous pouvez en permettre l'accès à l'aide
+de la directive UserDir en
+décommentant la ligne
+ #Include conf/extra/httpd-userdir.conf
+
dans le fichier de configuration par défaut, et en adaptant le
+ fichier httpd-userdir.conf selon vos besoins, ou en
+ incluant les directives appropriées dans une section
+ Directory du fichier de configuration principal.
Répertoires web utilisateurs Définition du chemin des fichiers avec UserDir Redirection vers des URLs externes Définition de la liste des utilisateurs autorisés à utiliser
+ cette fonctionnalité Définition d'un répertoire CGI pour chaque utilisateur Permettre aux utilisateurs de modifier la
+ configuration| Modules Apparentés | Directives Apparentées |
|---|---|
La directive UserDir
+ permet de spécifier un répertoire à partir duquel le contenu de
+ l'utilisateur pourra être chargé. Elle peut revêtir plusieurs
+ formes.
Si le chemin spécifié ne commence pas par un slash, il sera + interprété comme chemin relatif au répertoire home de l'utilisateur + considéré. Par exemple, avec cette configuration :
+ +
+ UserDir public_html
+
l'URL http://exemple.com/~rbowen/fichier.html
+ correspondra au chemin fichier
+ /home/rbowen/public_html/fichier.html
Si le chemin spécifié commence par un slash, le chemin du fichier + sera construit en utilisant ce chemin, suivi du nom de l'utilisateur + considéré. Par exemple, avec cette configuration :
+ +
+ UserDir /var/html
+
l'URL http://exemple.com/~rbowen/fichier.html
+ correspondra au chemin fichier
+ /var/html/rbowen/fichier.html
Si le chemin spécifié contient un astérisque (*), ce dernier sera + remplacé par le nom de l'utilisateur dans le chemin du fichier + correspondant. Par exemple, avec cette configuration :
+ +
+ UserDir /var/www/*/docs
+
l'URL http://exemple.com/~rbowen/fichier.html
+ correspondra au chemin fichier
+ /var/www/rbowen/docs/fichier.html
On peut aussi définir plusieurs répertoires ou chemins de + répertoires.
+ +
+ UserDir public_html /var/html
+
Avec l'URL http://exemple.com/~rbowen/fichier.html,
+ Apache va rechercher ~rbowen. S'il ne le trouve pas,
+ Apache va rechercher rbowen dans
+ /var/html. S'il le trouve, l'URL ci-dessus correspondra
+ au chemin fichier /var/html/rbowen/file.html
On peut utiliser la directive UserDir pour rediriger les requêtes
+ relatives aux répertoires utilisateurs vers des URLs externes.
+ UserDir http://exemple.org/users/*/
+
L'exemple ci-dessus va rediriger une requête pour
+ http://exemple.com/~bob/abc.html vers
+ http://exemple.org/users/bob/abc.html.
En suivant la syntaxe décrite dans la documentation de UserDir, + vous pouvez définir quels utilisateurs sont autorisés à utiliser + cette fonctionnalité :
+ +
+ UserDir enabled
+ UserDir disabled root jro fish
+
La configuration ci-dessus va autoriser l'utilisation de la
+ fonctionnalité pour tous les utilisateurs, à l'exception de ceux
+ listés à la suite de l'argument disabled. De même, vous
+ pouvez interdire l'utilisation de la fonctionnalité à tous les
+ utilisateurs sauf certains d'entre eux en utilisant une
+ configuration du style :
+ UserDir disabled
+ UserDir enabled rbowen krietz
+
Vous trouverez d'autres exemples dans la documentation de
+ UserDir.
Afin de réserver un répertoire cgi-bin pour chaque utilisateur,
+ vous pouvez utiliser une section <Directory> pour activer CGI dans un
+ sous-répertoire particulier d'un répertoire home utilisateur.
+ <Directory /home/*/public_html/cgi-bin/>
+ Options ExecCGI
+ SetHandler cgi-script
+ </Directory>
+
Avec la configuration ci-dessus, et en supposant que
+ UserDir est défini à public_html, un
+ programme CGI exemple.cgi pourra être chargé depuis ce
+ répertoire en passant par l'URL :
+ http://exemple.com/~rbowen/cgi-bin/exemple.cgi
+
Si vous voulez que vos utilisateurs puissent modifier la
+ configuration du serveur pour ce qui concerne leur espace web, ils
+ devront utiliser des fichiers .htaccess pour effectuer
+ ces modifications. Assurez-vous d'avoir défini la directive
+ AllowOverride à une valeur
+ appropriée pour les directives dont vous voulez permettre la
+ modification aux utilisateurs. Voir le tutoriel .htaccess pour plus de détails sur
+ la manière dont tout ceci fonctionne.
Serveur Apache HTTP Version 2.3
-Les SSI permettent d'ajouter du contenu dynamique à des documents -HTML préexistants.
-| Modules Apparentés | Directives Apparentées |
|---|---|
Cet article traite des Inclusions Côté Serveur (Server Side - Includes), plus communément appelés SSI. Vous trouverez ici la - manière de configurer votre serveur pour permettre les SSI, ainsi - qu'une introduction à quelques techniques SSI de base permettant - d'ajouter du contenu dynamique à vos pages HTML préexistantes.
- -La dernière partie de cet article sera consacrée aux - configurations SSI plus avancées, telles que les expressions - conditionnelles dans les directives SSI.
- -SSI (Server Side Includes) est constitué de directives placées dans - des pages HTML, et évaluées par le serveur au moment où les pages - sont servies. Elles vous permettent d'ajouter du contenu généré - dynamiquement à une page HTML préexistante, sans avoir à servir la - page entière via un programme CGI, ou toute autre technologie de - contenu dynamique.
- -Le choix entre l'utilisation des SSI et la génération entière de - la page par un programme quelconque, est en général dicté par la - proportion de contenu statique et de contenu devant être généré - chaque fois que la page est servie. SSI est idéal pour ajouter de - petites quantités d'information, comme l'heure courante. Mais si la - plus grande partie de votre page est générée au moment où elle est - servie, vous devez vous tourner vers une autre solution.
-Pour permettre l'utilisation des SSI sur votre serveur, vous
- devez ajouter la directive suivante dans votre fichier
- httpd.conf, ou dans un fichier .htaccess
- :
- Options +Includes
-
Cette directive indique à Apache que vous désirez permettre la
- recherche de directives SSI lors de l'interprétation des fichiers.
- Notez cependant que la plupart des configurations contiennent de
- nombreuses directives Options
- qui peuvent s'écraser les unes les autres. Vous devrez probablement
- appliquer ces directives Options au répertoire
- spécifique pour lequel vous voulez activer les SSI, afin d'être sûr
- qu'elles y seront bien activées.
Tout fichier ne fera cependant pas l'objet de recherche de
- directives SSI. Vous devez indiquer à Apache quels fichiers seront
- concernés. Vous pouvez y parvenir en indiquant une extension, comme
- .shtml, à l'aide des directives suivantes :
- AddType text/html .shtml
- AddOutputFilter INCLUDES .shtml
-
Un des désavantages de cette approche réside dans le fait que si
- vous voulez ajouter des directives SSI à une page préexistante, vous
- devrez changer le nom de cette page, et donc tout lien qui la
- contient, de façon à ce qu'elle possède l'extension
- .shtml, condition nécessaire pour que les directives
- SSI qu'elle contient soient traitées.
Une autre méthode consiste à utiliser la directive XBitHack :
- XBitHack on
-
La directive XBitHack
- indique à Apache qu'il doit rechercher des directivves SSI dans les
- fichiers si leur bit d'exécution est positionné. Il n'est ainsi plus
- nécessaire de changer le nom du fichier pour ajouter des directives
- SSI à une page préexistante ; vous devez simplement attribuer les
- droits d'exécution au fichier à l'aide de chmod.
- chmod +x pagename.html
-
Un bref commentaire sur ce qu'il ne faut pas faire. Certaines
- personnes peuvent vous conseiller de tout simplement indiquer à
- Apache de rechercher des directives SSI dans tous les fichiers
- .html, ce qui vous évite d'avoir à gérer les noms de
- fichiers avec extension .shtml. Ils n'ont probablement
- pas entendu parler de la directive XBitHack. En effet, vous devez
- garder à l'esprit qu'en faisant ceci, Apache va devoir rechercher
- des directives SSI dans chaque fichier qu'il sert, même s'il n'en
- contient aucune. Ce n'est donc pas une bonne idée car les
- performances peuvent en être sensiblement affectées.
Bien entendu, sous Windows, il n'y a pas de bit d'exécution à - positionner, ce qui limite un peu vos choix.
- -Dans sa configuration par défaut, Apache n'envoie pas la date de - dernière modification ou les en-têtes HTTP relatifs à la taille des - contenus dans les pages SSI, car ses valeurs sont difficiles à - calculer pour les contenus dynamiques. Ceci peut induire une - impression de diminution des performances côté client, en empêchant - la mise en cache de votre document. Il existe deux méthodes pour - résoudre ce problème :
- -XBitHack Full. Elle
- indique à Apache de déterminer la date de dernière modification en
- ne regardant que la date du fichier à l'origine de la requête,
- tout en ignorant la date de modification de tout fichier inclus.mod_expires pour définir de manière explicite la
- date d'expiration de vos fichiers, laissant par la-même
- aux navigateurs et aux mandataires le soin de déterminer s'il est
- opportun ou non de les mettre en cache.Les directives SSI adoptent la syntaxe suivante :
-
- <!--#élément attribut=valeur attribut=valeur ... -->
-
Le format d'une directive SSI étant similaire à celui d'un - commentaire HTML, si vous n'avez pas activé correctement SSI, le - navigateur l'ignorera, mais elle sera encore visible dans le source - HTML. Si SSI est correctement configuré, la directive sera remplacée - par ses résultats.
- -"élément" peut prendre de nombreuses formes, et nous décrirons - plus précisément la plupart d'entre eux dans la prochaine version de - ce document. Pour le moment, voici quelques exemples de ce que vous - pouvez faire avec SSI.
- -
- <!--#echo var="DATE_LOCAL" -->
-
L'élément echo permet d'afficher la valeur d'une
- variable. Il existe un grand nombre de variables standards, y
- compris l'ensemble des variables d'environnement disponibles pour
- les programmes CGI. De plus, vous pouvez définir vos propres
- variables à l'aide de l'élément set.
Si vous n'aimez pas le format sous lequel la date s'affiche, vous
- pouvez utiliser l'élément config avec un attribut
- timefmt, pour le modifier.
- <!--#config timefmt="%A %B %d, %Y" -->
- Today is <!--#echo var="DATE_LOCAL" -->
-
- Dernière modification du document <!--#flastmod file="index.html" -->
-
Le format peut là aussi être modifié à l'aide de l'attribut
- timefmt.
C'est le cas le plus courant d'utilisation des SSI - afficher les - résultats d'un programme CGI, comme l'universellement adoré - "compteur d'accès".
- -
- <!--#include virtual="/cgi-bin/counter.pl" -->
-
Vous trouverez dans ce qui suit quelques exemples spécifiques de - ce que vous pouvez faire de vos documents HTML avec SSI.
- -Nous avons mentionné plus haut que vous pouviez utiliser SSI pour - informer l'utilisateur de la date de dernière modification du - document. Cependant, la méthode pour y parvenir n'a pas été vraiment - abordée. Placé dans votre document HTML, le code suivant va insérer - un repère de temps dans votre page. Bien entendu, SSI devra avoir - été correctement activé, comme décrit plus haut.
-
- <!--#config timefmt="%A %B %d, %Y" -->
- Dernière modification du fichier <!--#flastmod file="ssi.shtml" -->
-
Bien entendu, vous devez remplacer ssi.shtml par le
- nom du fichier auquel vous faites référence. Ceci ne conviendra pas
- si vous recherchez un morceau de code générique que vous pourrez
- insérer dans tout fichier ; dans ce cas, il est préférable
- d'utiliser la variable LAST_MODIFIED :
- <!--#config timefmt="%D" -->
- This file last modified <!--#echo var="LAST_MODIFIED" -->
-
Pour plus de détails sur le format timefmt, tapez
- strftime dans votre moteur de recherche préferé. La
- syntaxe est identique.
Si le site que vous gérez comporte plus que quelques pages, vous - allez vite vous apercevoir qu'effectuer des modifications sur toutes - ces pages peut devenir très contraignant, en particulier si vous - voulez qu'elles conservent un aspect homogène.
- -Inclure un fichier pour un en-tête et/ou un pied de page peut
- simplifier cette corvée de mises à jour. Il vous suffit de
- confectionner un fichier de pied de page, et de l'inclure dans
- chaque page à l'aide de l'élément SSI include. Pour
- définir le fichier à inclure, l'élément include peut
- utiliser soit l'attribut file, soit l'attribut
- virtual. L'attribut file est un chemin de
- fichier relatif au répertoire courant. C'est à dire qu'il
- ne peut ni avoir pour valeur un chemin absolu (commençant par /), ni
- comporter "../" dans son chemin. L'attribut virtual est
- probablement plus commode, et peut spécifier une URL relative au
- document servi. Elle peut commencer par un /, mais le fichier inclus
- et le fichier servi doivent résider sur le même serveur.
- <!--#include virtual="/footer.html" -->
-
Je combinerai souvent ces deux derniers points, en ajoutant une
- directive LAST_MODIFIED dans un fichier de pied de page
- destiné à être inclus. Le fichier inclus peut contenir des
- directives SSI, et les inclusions peuvent être imbriquées - à
- savoir, le fichier inclus peut inclure un autre fichier, etc...
En plus du format de date, vous pouvez utiliser l'élément
- config pour configurer deux autres choses.
En général, lorsque quelque chose se passe mal avec votre - directive SSI, vous recevez le message :
-
- [an error occurred while processing this directive]
-
Pour modifier ce message, vous pouvez utiliser l'attribut
- errmsg avec l'élément config :
- <!--#config errmsg="[Il semblerait que vous ne sachiez pas
- utiliser les SSI]" -->
-
Il est cependant probable que les utilisateurs finaux ne voient - jamais ce message, car vous aurez résolu tous les problèmes issus de - vos directives SSI avant que votre site ne soit mis en production. - (N'est-ce pas ?)
- -Vous pouvez aussi modifier le format sous lequel les tailles de
- fichiers sont affichées à l'aide de l'attribut sizefmt.
- Vous pouvez spécifier bytes pour un affichage en
- octets, ou abbrev pour un affichage plus concis en Ko
- ou Mo, selon le cas.
J'ai pour projet, dans les prochains mois, d'écrire un article à
- propos de l'utilisation des SSI avec des petits programmes CGI. Pour
- l'instant, voici ce que vous pouvez faire avec l'élément
- exec. Vous pouvez vraiment faire exécuter une commande
- par SSI en utilisant le shell (/bin/sh, pour être plus
- précis - ou le shell DOS, si vous êtes sous Win32). Par exemple, ce
- qui suit vous permet d'afficher le contenu d'un répertoire.
- <pre>
- <!--#exec cmd="ls" -->
- </pre>
-
ou, sous Windows
-
- <pre>
- <!--#exec cmd="dir" -->
- </pre>
-
Vous noterez probablement l'étrange formatage provoqué par cette
- directive sous Windows, car la sortie de dir contient
- la chaîne de caractères "<dir>", ce qui trompe le
- navigateur.
Notez que cette fonctionnalité est très dangereuse, car elle va
- permettre d'exécuter tout code associé à l'élément
- exec. Si vous êtes dans la situation où les
- utilisateurs peuvent éditer le contenu de vos pages web, dans le cas
- d'un "livre d'or" par exemple, assurez-vous de désactiver cette
- fonctionnalité. Vous pouvez, tout en permettant les SSI, désactiver
- la fonctionnalité exec à l'aide de l'argument
- IncludesNOEXEC de la directive
- Options.
Outre l'affichage de contenu, les SSI d'Apache vous permettent de - définir des variables, et de les utiliser dans des comparaisons et - des conditions.
- -La plupart des fonctionnalités décrites dans cet article ne sont - disponibles que si vous utilisez la version 1.2 ou supérieure - d'Apache. Bien entendu, si ce n'est pas le cas, vous devez faire une - mise à jour immédiatement, et même plus tôt. Allez-y. Faites-le - maintenant. Nous attendrons.
- - -Avec l'élément set, vous pouvez définir des
- variables pour un usage ultérieur. Comme nous en aurons besoin plus
- loin, nous allons en parler tout de suite. La syntaxe se présente
- comme suit :
- <!--#set var="name" value="Rich" -->
-
Pour affecter une valeur à vos variables, en plus de la
- définition littérale de l'exemple ci-dessus, vous pouvez utiliser
- une autre variable, y compris les variables d'environnement, ou les variables
- décrites plus haut (comme LAST_MODIFIED par exemple).
- Pour indiquer qu'il s'agit d'une variable et non d'une chaîne, vous
- devez utiliser le symbole dollar ($) devant le nom de la
- variable.
<!--#set var="modified" value="$LAST_MODIFIED" -->
-
Pour insérer un caractère $ dans la valeur de votre variable, - vous devez l'échapper à l'aide d'un backslash.
-
- <!--#set var="cost" value="\$100" -->
-
Enfin, si vous voulez insérer une variable dans une chaîne, et - s'il y a une chance pour que le nom de la variable se confonde avec - le reste de la chaîne, vous pouvez l'entourer d'accolades pour - eviter toute confusion (Il est difficile de trouver un bon exemple - pour illustrer ceci, mais j'espère que vous comprendrez).
-
- <!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" -->
-
Maintenent que nous avons des variables, et que nous pouvons
- définir et comparer leurs valeurs, nous sommes à même de les
- utiliser dans des expressions conditionnelles. Ceci confère à SSI le
- statut de petit langage de programmation.
- mod_include fournit une structure if,
- elif, else, endif pour la
- construction d'expressions conditionnelles, ce qui vous permet de
- générer plusieurs pages logiques à partir d'une seule vraie
- page.
La structure de l'expression conditionnelle est :
-
- <!--#if expr="condition" -->
- <!--#elif expr="condition" -->
- <!--#else -->
- <!--#endif -->
-
Une condition peut revêtir la forme de toute comparaison
- logique - soit une comparaison de valeurs avec une autre, soit une
- vérification de la "vérité" d'une valeur particulière (Une chaîne
- donnée est vraie si elle n'est pas vide). Pour une liste exhaustive
- des opérateurs de comparaison disponibles, voir la documentation du
- module mod_include. Voici quelques exemples
- illustrant l'utilisation de ces expressions.
Vous pouvez ajouter les lignes suivantes dans votre fichier de - configuration :
-
- BrowserMatchNoCase macintosh Mac
- BrowserMatchNoCase MSIE InternetExplorer
-
Ces lignes définissent les variables d'environnement "Mac" et - "InternetExplorer" à true, si le client utilise InternetExplorer sur - un Macintosh.
- -Puis, dans votre document où les SSI sont activées, vous ajoutez - ceci :
-
- <!--#if expr="${Mac} && ${InternetExplorer}" -->
- Un texte d'excuses est inséré ici
- <!--#else -->
- Ici se trouve du code JavaScipt sympa
- <!--#endif -->
-
Notez que je n'ai rien contre IE sur Macintosh - J'ai juste - phosphoré quelques heures la semaine dernière pour faire fonctionner - du JavaScript sous IE sur Macintosh, alors qu'il fonctionnait sous - tout autre environnement. Ce qui précède a constitué un - contournement provisoire.
- -Toute autre variable (que vous avez définie, ou une variable
- d'environnement normale) peut être utilisée dans les expressions
- conditionnelles. Associée à la possibilité avec Apache de définir
- des variables d'environnement à l'aide de directives
- SetEnvIf, ainsi que d'autres directives en rapport,
- cette fonctionnalité vous permet d'ajouter des contenus dynamiques
- assez évolués sans avoir recours aux programmes CGI.
SSI ne remplace certainement pas CGI, ou d'autres technologies - utilisées pour la génération de pages web dynamiques. Mais c'est une - bonne méthode pour ajouter des petits contenus dynamiques à vos - pages, sans devoir fournir un gros effort supplémentaire.
-Serveur Apache HTTP Version 2.3
+Les SSI permettent d'ajouter du contenu dynamique à des documents +HTML préexistants.
+| Modules Apparentés | Directives Apparentées |
|---|---|
Cet article traite des Inclusions Côté Serveur (Server Side + Includes), plus communément appelés SSI. Vous trouverez ici la + manière de configurer votre serveur pour permettre les SSI, ainsi + qu'une introduction à quelques techniques SSI de base permettant + d'ajouter du contenu dynamique à vos pages HTML préexistantes.
+ +La dernière partie de cet article sera consacrée aux + configurations SSI plus avancées, telles que les expressions + conditionnelles dans les directives SSI.
+ +SSI (Server Side Includes) est constitué de directives placées dans + des pages HTML, et évaluées par le serveur au moment où les pages + sont servies. Elles vous permettent d'ajouter du contenu généré + dynamiquement à une page HTML préexistante, sans avoir à servir la + page entière via un programme CGI, ou toute autre technologie de + contenu dynamique.
+ +Le choix entre l'utilisation des SSI et la génération entière de + la page par un programme quelconque, est en général dicté par la + proportion de contenu statique et de contenu devant être généré + chaque fois que la page est servie. SSI est idéal pour ajouter de + petites quantités d'information, comme l'heure courante. Mais si la + plus grande partie de votre page est générée au moment où elle est + servie, vous devez vous tourner vers une autre solution.
+Pour permettre l'utilisation des SSI sur votre serveur, vous
+ devez ajouter la directive suivante dans votre fichier
+ httpd.conf, ou dans un fichier .htaccess
+ :
+ Options +Includes
+
Cette directive indique à Apache que vous désirez permettre la
+ recherche de directives SSI lors de l'interprétation des fichiers.
+ Notez cependant que la plupart des configurations contiennent de
+ nombreuses directives Options
+ qui peuvent s'écraser les unes les autres. Vous devrez probablement
+ appliquer ces directives Options au répertoire
+ spécifique pour lequel vous voulez activer les SSI, afin d'être sûr
+ qu'elles y seront bien activées.
Tout fichier ne fera cependant pas l'objet de recherche de
+ directives SSI. Vous devez indiquer à Apache quels fichiers seront
+ concernés. Vous pouvez y parvenir en indiquant une extension, comme
+ .shtml, à l'aide des directives suivantes :
+ AddType text/html .shtml
+ AddOutputFilter INCLUDES .shtml
+
Un des désavantages de cette approche réside dans le fait que si
+ vous voulez ajouter des directives SSI à une page préexistante, vous
+ devrez changer le nom de cette page, et donc tout lien qui la
+ contient, de façon à ce qu'elle possède l'extension
+ .shtml, condition nécessaire pour que les directives
+ SSI qu'elle contient soient traitées.
Une autre méthode consiste à utiliser la directive XBitHack :
+ XBitHack on
+
La directive XBitHack
+ indique à Apache qu'il doit rechercher des directivves SSI dans les
+ fichiers si leur bit d'exécution est positionné. Il n'est ainsi plus
+ nécessaire de changer le nom du fichier pour ajouter des directives
+ SSI à une page préexistante ; vous devez simplement attribuer les
+ droits d'exécution au fichier à l'aide de chmod.
+ chmod +x pagename.html
+
Un bref commentaire sur ce qu'il ne faut pas faire. Certaines
+ personnes peuvent vous conseiller de tout simplement indiquer à
+ Apache de rechercher des directives SSI dans tous les fichiers
+ .html, ce qui vous évite d'avoir à gérer les noms de
+ fichiers avec extension .shtml. Ils n'ont probablement
+ pas entendu parler de la directive XBitHack. En effet, vous devez
+ garder à l'esprit qu'en faisant ceci, Apache va devoir rechercher
+ des directives SSI dans chaque fichier qu'il sert, même s'il n'en
+ contient aucune. Ce n'est donc pas une bonne idée car les
+ performances peuvent en être sensiblement affectées.
Bien entendu, sous Windows, il n'y a pas de bit d'exécution à + positionner, ce qui limite un peu vos choix.
+ +Dans sa configuration par défaut, Apache n'envoie pas la date de + dernière modification ou les en-têtes HTTP relatifs à la taille des + contenus dans les pages SSI, car ses valeurs sont difficiles à + calculer pour les contenus dynamiques. Ceci peut induire une + impression de diminution des performances côté client, en empêchant + la mise en cache de votre document. Il existe deux méthodes pour + résoudre ce problème :
+ +XBitHack Full. Elle
+ indique à Apache de déterminer la date de dernière modification en
+ ne regardant que la date du fichier à l'origine de la requête,
+ tout en ignorant la date de modification de tout fichier inclus.mod_expires pour définir de manière explicite la
+ date d'expiration de vos fichiers, laissant par la-même
+ aux navigateurs et aux mandataires le soin de déterminer s'il est
+ opportun ou non de les mettre en cache.Les directives SSI adoptent la syntaxe suivante :
+
+ <!--#élément attribut=valeur attribut=valeur ... -->
+
Le format d'une directive SSI étant similaire à celui d'un + commentaire HTML, si vous n'avez pas activé correctement SSI, le + navigateur l'ignorera, mais elle sera encore visible dans le source + HTML. Si SSI est correctement configuré, la directive sera remplacée + par ses résultats.
+ +"élément" peut prendre de nombreuses formes, et nous décrirons + plus précisément la plupart d'entre eux dans la prochaine version de + ce document. Pour le moment, voici quelques exemples de ce que vous + pouvez faire avec SSI.
+ +
+ <!--#echo var="DATE_LOCAL" -->
+
L'élément echo permet d'afficher la valeur d'une
+ variable. Il existe un grand nombre de variables standards, y
+ compris l'ensemble des variables d'environnement disponibles pour
+ les programmes CGI. De plus, vous pouvez définir vos propres
+ variables à l'aide de l'élément set.
Si vous n'aimez pas le format sous lequel la date s'affiche, vous
+ pouvez utiliser l'élément config avec un attribut
+ timefmt, pour le modifier.
+ <!--#config timefmt="%A %B %d, %Y" -->
+ Today is <!--#echo var="DATE_LOCAL" -->
+
+ Dernière modification du document <!--#flastmod file="index.html" -->
+
Le format peut là aussi être modifié à l'aide de l'attribut
+ timefmt.
C'est le cas le plus courant d'utilisation des SSI - afficher les + résultats d'un programme CGI, comme l'universellement adoré + "compteur d'accès".
+ +
+ <!--#include virtual="/cgi-bin/counter.pl" -->
+
Vous trouverez dans ce qui suit quelques exemples spécifiques de + ce que vous pouvez faire de vos documents HTML avec SSI.
+ +Nous avons mentionné plus haut que vous pouviez utiliser SSI pour + informer l'utilisateur de la date de dernière modification du + document. Cependant, la méthode pour y parvenir n'a pas été vraiment + abordée. Placé dans votre document HTML, le code suivant va insérer + un repère de temps dans votre page. Bien entendu, SSI devra avoir + été correctement activé, comme décrit plus haut.
+
+ <!--#config timefmt="%A %B %d, %Y" -->
+ Dernière modification du fichier <!--#flastmod file="ssi.shtml" -->
+
Bien entendu, vous devez remplacer ssi.shtml par le
+ nom du fichier auquel vous faites référence. Ceci ne conviendra pas
+ si vous recherchez un morceau de code générique que vous pourrez
+ insérer dans tout fichier ; dans ce cas, il est préférable
+ d'utiliser la variable LAST_MODIFIED :
+ <!--#config timefmt="%D" -->
+ This file last modified <!--#echo var="LAST_MODIFIED" -->
+
Pour plus de détails sur le format timefmt, tapez
+ strftime dans votre moteur de recherche préferé. La
+ syntaxe est identique.
Si le site que vous gérez comporte plus que quelques pages, vous + allez vite vous apercevoir qu'effectuer des modifications sur toutes + ces pages peut devenir très contraignant, en particulier si vous + voulez qu'elles conservent un aspect homogène.
+ +Inclure un fichier pour un en-tête et/ou un pied de page peut
+ simplifier cette corvée de mises à jour. Il vous suffit de
+ confectionner un fichier de pied de page, et de l'inclure dans
+ chaque page à l'aide de l'élément SSI include. Pour
+ définir le fichier à inclure, l'élément include peut
+ utiliser soit l'attribut file, soit l'attribut
+ virtual. L'attribut file est un chemin de
+ fichier relatif au répertoire courant. C'est à dire qu'il
+ ne peut ni avoir pour valeur un chemin absolu (commençant par /), ni
+ comporter "../" dans son chemin. L'attribut virtual est
+ probablement plus commode, et peut spécifier une URL relative au
+ document servi. Elle peut commencer par un /, mais le fichier inclus
+ et le fichier servi doivent résider sur le même serveur.
+ <!--#include virtual="/footer.html" -->
+
Je combinerai souvent ces deux derniers points, en ajoutant une
+ directive LAST_MODIFIED dans un fichier de pied de page
+ destiné à être inclus. Le fichier inclus peut contenir des
+ directives SSI, et les inclusions peuvent être imbriquées - à
+ savoir, le fichier inclus peut inclure un autre fichier, etc...
En plus du format de date, vous pouvez utiliser l'élément
+ config pour configurer deux autres choses.
En général, lorsque quelque chose se passe mal avec votre + directive SSI, vous recevez le message :
+
+ [an error occurred while processing this directive]
+
Pour modifier ce message, vous pouvez utiliser l'attribut
+ errmsg avec l'élément config :
+ <!--#config errmsg="[Il semblerait que vous ne sachiez pas
+ utiliser les SSI]" -->
+
Il est cependant probable que les utilisateurs finaux ne voient + jamais ce message, car vous aurez résolu tous les problèmes issus de + vos directives SSI avant que votre site ne soit mis en production. + (N'est-ce pas ?)
+ +Vous pouvez aussi modifier le format sous lequel les tailles de
+ fichiers sont affichées à l'aide de l'attribut sizefmt.
+ Vous pouvez spécifier bytes pour un affichage en
+ octets, ou abbrev pour un affichage plus concis en Ko
+ ou Mo, selon le cas.
J'ai pour projet, dans les prochains mois, d'écrire un article à
+ propos de l'utilisation des SSI avec des petits programmes CGI. Pour
+ l'instant, voici ce que vous pouvez faire avec l'élément
+ exec. Vous pouvez vraiment faire exécuter une commande
+ par SSI en utilisant le shell (/bin/sh, pour être plus
+ précis - ou le shell DOS, si vous êtes sous Win32). Par exemple, ce
+ qui suit vous permet d'afficher le contenu d'un répertoire.
+ <pre>
+ <!--#exec cmd="ls" -->
+ </pre>
+
ou, sous Windows
+
+ <pre>
+ <!--#exec cmd="dir" -->
+ </pre>
+
Vous noterez probablement l'étrange formatage provoqué par cette
+ directive sous Windows, car la sortie de dir contient
+ la chaîne de caractères "<dir>", ce qui trompe le
+ navigateur.
Notez que cette fonctionnalité est très dangereuse, car elle va
+ permettre d'exécuter tout code associé à l'élément
+ exec. Si vous êtes dans la situation où les
+ utilisateurs peuvent éditer le contenu de vos pages web, dans le cas
+ d'un "livre d'or" par exemple, assurez-vous de désactiver cette
+ fonctionnalité. Vous pouvez, tout en permettant les SSI, désactiver
+ la fonctionnalité exec à l'aide de l'argument
+ IncludesNOEXEC de la directive
+ Options.
Outre l'affichage de contenu, les SSI d'Apache vous permettent de + définir des variables, et de les utiliser dans des comparaisons et + des conditions.
+ +La plupart des fonctionnalités décrites dans cet article ne sont + disponibles que si vous utilisez la version 1.2 ou supérieure + d'Apache. Bien entendu, si ce n'est pas le cas, vous devez faire une + mise à jour immédiatement, et même plus tôt. Allez-y. Faites-le + maintenant. Nous attendrons.
+ + +Avec l'élément set, vous pouvez définir des
+ variables pour un usage ultérieur. Comme nous en aurons besoin plus
+ loin, nous allons en parler tout de suite. La syntaxe se présente
+ comme suit :
+ <!--#set var="name" value="Rich" -->
+
Pour affecter une valeur à vos variables, en plus de la
+ définition littérale de l'exemple ci-dessus, vous pouvez utiliser
+ une autre variable, y compris les variables d'environnement, ou les variables
+ décrites plus haut (comme LAST_MODIFIED par exemple).
+ Pour indiquer qu'il s'agit d'une variable et non d'une chaîne, vous
+ devez utiliser le symbole dollar ($) devant le nom de la
+ variable.
<!--#set var="modified" value="$LAST_MODIFIED" -->
+
Pour insérer un caractère $ dans la valeur de votre variable, + vous devez l'échapper à l'aide d'un backslash.
+
+ <!--#set var="cost" value="\$100" -->
+
Enfin, si vous voulez insérer une variable dans une chaîne, et + s'il y a une chance pour que le nom de la variable se confonde avec + le reste de la chaîne, vous pouvez l'entourer d'accolades pour + eviter toute confusion (Il est difficile de trouver un bon exemple + pour illustrer ceci, mais j'espère que vous comprendrez).
+
+ <!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" -->
+
Maintenent que nous avons des variables, et que nous pouvons
+ définir et comparer leurs valeurs, nous sommes à même de les
+ utiliser dans des expressions conditionnelles. Ceci confère à SSI le
+ statut de petit langage de programmation.
+ mod_include fournit une structure if,
+ elif, else, endif pour la
+ construction d'expressions conditionnelles, ce qui vous permet de
+ générer plusieurs pages logiques à partir d'une seule vraie
+ page.
La structure de l'expression conditionnelle est :
+
+ <!--#if expr="condition" -->
+ <!--#elif expr="condition" -->
+ <!--#else -->
+ <!--#endif -->
+
Une condition peut revêtir la forme de toute comparaison
+ logique - soit une comparaison de valeurs avec une autre, soit une
+ vérification de la "vérité" d'une valeur particulière (Une chaîne
+ donnée est vraie si elle n'est pas vide). Pour une liste exhaustive
+ des opérateurs de comparaison disponibles, voir la documentation du
+ module mod_include. Voici quelques exemples
+ illustrant l'utilisation de ces expressions.
Vous pouvez ajouter les lignes suivantes dans votre fichier de + configuration :
+
+ BrowserMatchNoCase macintosh Mac
+ BrowserMatchNoCase MSIE InternetExplorer
+
Ces lignes définissent les variables d'environnement "Mac" et + "InternetExplorer" à true, si le client utilise InternetExplorer sur + un Macintosh.
+ +Puis, dans votre document où les SSI sont activées, vous ajoutez + ceci :
+
+ <!--#if expr="${Mac} && ${InternetExplorer}" -->
+ Un texte d'excuses est inséré ici
+ <!--#else -->
+ Ici se trouve du code JavaScipt sympa
+ <!--#endif -->
+
Notez que je n'ai rien contre IE sur Macintosh - J'ai juste + phosphoré quelques heures la semaine dernière pour faire fonctionner + du JavaScript sous IE sur Macintosh, alors qu'il fonctionnait sous + tout autre environnement. Ce qui précède a constitué un + contournement provisoire.
+ +Toute autre variable (que vous avez définie, ou une variable
+ d'environnement normale) peut être utilisée dans les expressions
+ conditionnelles. Associée à la possibilité avec Apache de définir
+ des variables d'environnement à l'aide de directives
+ SetEnvIf, ainsi que d'autres directives en rapport,
+ cette fonctionnalité vous permet d'ajouter des contenus dynamiques
+ assez évolués sans avoir recours aux programmes CGI.
SSI ne remplace certainement pas CGI, ou d'autres technologies + utilisées pour la génération de pages web dynamiques. Mais c'est une + bonne méthode pour ajouter des petits contenus dynamiques à vos + pages, sans devoir fournir un gros effort supplémentaire.
+Serveur Apache HTTP Version 2.3
-Vous trouverez plus loin une liste de pages de documentation - additionnelles concernant le projet de développement du serveur web - Apache.
- -La mise à jour des documents ci-dessous permettant de prendre en - compte les modifications apportées par la version 2.1 du serveur - HTTP Apache n'a pas été entièrement menée à bien. Certaines - informations sont probablement encore pertinentes, mais utilisez-les tout de même avec - précautions.
-Notes à propos de la configuration d'Apache pour de plus - hautes performances (à l'exécution et à la compilation). Notes - expliquant pourquoi Apache accomplit certaines choses et - n'en accomplit pas certaines autres (les premières l'accélérant - et les deuxièmes le ralentissant).
-Quelques conseils de type "faites" ou "ne faites pas" pour - que votre site web Apache reste sécurisé.
-Ce document constitue une page de référence pour la plupart - des standards concernés par Apache.
-Discussion à propos des divers algorithmes de chiffrement - supportés par Apache à des fins d'authentification.
-Serveur Apache HTTP Version 2.3
+Vous trouverez plus loin une liste de pages de documentation + additionnelles concernant le projet de développement du serveur web + Apache.
+ +La mise à jour des documents ci-dessous permettant de prendre en + compte les modifications apportées par la version 2.1 du serveur + HTTP Apache n'a pas été entièrement menée à bien. Certaines + informations sont probablement encore pertinentes, mais utilisez-les tout de même avec + précautions.
+Notes à propos de la configuration d'Apache pour de plus + hautes performances (à l'exécution et à la compilation). Notes + expliquant pourquoi Apache accomplit certaines choses et + n'en accomplit pas certaines autres (les premières l'accélérant + et les deuxièmes le ralentissant).
+Quelques conseils de type "faites" ou "ne faites pas" pour + que votre site web Apache reste sécurisé.
+Ce document constitue une page de référence pour la plupart + des standards concernés par Apache.
+Discussion à propos des divers algorithmes de chiffrement + supportés par Apache à des fins d'authentification.
+Serveur Apache HTTP Version 2.3
-Apache 2.x est un serveur web à usage général, conçu dans un but - d'équilibre entre souplesse, portabilité et performances. Bien que non - conçu dans le seul but d'établir une référence en la matière, - Apache 2.x est capable de hautes performances dans de nombreuses situations - du monde réel.
- -Comparée à Apache 1.3, la version 2.x comporte de nombreuses - optimisations supplémentaires permettant d'améliorer le débit du serveur - et sa personnalisation. La plupart de ces améliorations sont activées par - défaut. Cependant, certains choix de configuration à la compilation et à - l'exécution peuvent affecter les performances de manière significative. Ce - document décrit les options qu'un administrateur de serveur peut configurer - pour améliorer les performances d'une installation d'Apache 2.x. Certaines - de ces options de configuration permettent au démon httpd de mieux tirer - parti des possibilités du matériel et du système d'exploitation, tandis - que d'autres permettent à l'administrateur de privilégier la vitesse - par rapport aux fonctionnalités.
- -Le principal problème matériel qui affecte les performances du serveur
- web est la mémoire vive (RAM). Un serveur web ne devrait jamais avoir à
- utiliser le swap, car le swapping augmente le temps de réponse de chaque
- requête au delà du point que les utilisateurs considèrent comme
- "trop lent". Ceci incite les utilisateurs à cliquer sur "Stop", puis
- "Charger à nouveau", ce qui a pour effet d'augmenter encore la charge
- du serveur. Vous pouvez, et même devez définir la valeur de la directive
- MaxClients de façon à ce que
- votre serveur ne lance pas un nombre de processus enfants tel qu'il
- commence à faire du swapping. La méthode pour y parvenir est
- simple : déterminez la taille de votre processus Apache standard en
- consultant votre liste de processus à l'aide d'un outil tel que
- top, et divisez votre quantité totale de mémoire disponible
- par cette taille, tout en gardant un espace suffisant
- pour les autres processus.
Hormis ce réglage relatif à la mémoire, le reste est trivial : le - processeur, la carte réseau et les disques doivent être suffisamment - rapides, où "suffisamment rapide" doit être déterminé par - l'expérience.
- -Le choix du système d'exploitation dépend principalement du - contexte local. Voici cependant quelques conseils qui se sont - généralement avérés utiles :
- -Exécutez la dernière version stable et le niveau de patches le - plus haut du système d'exploitation que vous avez choisi. De nombreux - éditeurs de systèmes d'exploitation ont amélioré de manière - significative les performances de leurs piles TCP et de leurs - bibliothèques de thread ces dernières années.
-Si votre système d'exploitation possède un appel système
- sendfile(2), assurez-vous d'avoir installé la version
- et/ou les patches nécessaires à son activation. (Pour Linux, par
- exemple, cela se traduit par Linux 2.4 ou plus. Pour les versions
- anciennes de Solaris 8, vous pouvez être amené à appliquer un patch.)
- Sur les systèmes où il est disponible, sendfile permet
- à Apache 2 de servir les contenus statiques plus rapidement, tout en
- induisant une charge CPU inférieure.
| Modules Apparentés | Directives Apparentées |
|---|---|
Avant Apache 1.3, la directive
- HostnameLookups était positionnée
- par défaut à On. Ce réglage augmente le temps de réponse de
- chaque requête car il entraîne une recherche DNS et le traitement de la
- requête ne pourra pas être achevé tant que cette recherche ne sera
- pas terminée. Avec Apache 1.3, ce réglage est défini par défaut à
- Off. Si vous souhaitez que les adresses dans vos fichiers
- journaux soient résolues en noms d'hôtes, utilisez le programme
- logresolve fourni avec Apache, ou un des nombreux
- paquets générateurs de rapports sur les journaux disponibles.
Il est recommandé d'effectuer ce genre de traitement a posteriori - de vos fichiers journaux sur une autre machine que celle qui héberge le - serveur web en production, afin que cette activité n'affecte pas les - performances du serveur.
- -Si vous utilisez une directive
- Allowfrom domainDeny from domain
Notez qu'il est possible de modifier la portée des directives, en les
- plaçant par exemple à l'intérieur d'une section
- <Location /server-status>. Les recherches DNS ne
- seront alors effectuées que pour les requêtes qui satisfont aux critères.
- Voici un exemple qui désactive les recherches DNS sauf pour les fichiers
- .html et .cgi :
- HostnameLookups off
- <Files ~ "\.(html|cgi)$">
-
- HostnameLookups on
-
- </Files>
-
Mais même dans ce cas, si vous n'avez besoin de noms DNS que dans
- certains CGIs, vous pouvez effectuer l'appel à gethostbyname
- dans les CGIs spécifiques qui en ont besoin.
Chaque fois que la ligne Options FollowSymLinks sera
- absente, ou que la ligne Options SymLinksIfOwnerMatch sera
- présente dans votre espace d'adressage, Apache devra effectuer des
- appels système supplémentaires pour vérifier la présence de liens
- symboliques. Un appel supplémentaire par élément du chemin du fichier.
- Par exemple, si vous avez :
- DocumentRoot /www/htdocs
- <Directory />
-
- Options SymLinksIfOwnerMatch
-
- </Directory>
-
et si une requête demande l'URI /index.html, Apache
- effectuera un appel à lstat(2) pour
- /www, /www/htdocs, et
- /www/htdocs/index.html. Les résultats de ces appels à
- lstat ne sont jamais mis en cache, ils devront donc être
- générés à nouveau pour chaque nouvelle requête. Si vous voulez absolument
- vérifier la sécurité des liens symboliques, vous pouvez utiliser une
- configuration du style :
- DocumentRoot /www/htdocs
- <Directory />
-
- Options FollowSymLinks
-
- </Directory>
-
- <Directory /www/htdocs>
-
- Options -FollowSymLinks +SymLinksIfOwnerMatch
-
- </Directory>
-
Ceci évite au moins les vérifications supplémentaires pour le chemin
- défini par DocumentRoot. Notez que
- vous devrez ajouter des sections similaires si vous avez des chemins
- définis par les directives
- Alias ou
- RewriteRule en dehors de
- la racine de vos documents. Pour améliorer les performances, et supprimer
- toute protection des liens symboliques, ajoutez l'option
- FollowSymLinks partout, et n'utilisez jamais l'option
- SymLinksIfOwnerMatch.
Dans toute partie de votre espace d'adressage où vous autoriserez
- la surcharge de la configuration (en général à l'aide de fichiers
- .htaccess), Apache va tenter d'ouvrir .htaccess
- pour chaque élément du chemin du fichier demandé. Par exemple, si vous
- avez :
- DocumentRoot /www/htdocs
- <Directory />
-
- AllowOverride all
-
- </Directory>
-
et qu'une requête demande l'URI /index.html, Apache
- tentera d'ouvrir /.htaccess, /www/.htaccess,
- et /www/htdocs/.htaccess. Les solutions sont similaires à
- celles évoquées précédemment pour Options FollowSymLinks.
- Pour améliorer les performances, utilisez AllowOverride None
- pour tous les niveaux de votre espace d'adressage.
Dans la mesure du possible, évitez toute négociation de contenu si - vous tenez au moindre gain en performances. En pratique toutefois, - les bénéfices de la négociation l'emportent souvent sur la diminution - des performances. - Il y a cependant un cas dans lequel vous pouvez accélérer le serveur. - Au lieu d'utiliser une directive générique comme :
- -
- DirectoryIndex index
-
utilisez une liste explicite d'options :
- -
- DirectoryIndex index.cgi index.pl index.shtml index.html
-
où vous placez le choix courant en première position.
- -Notez aussi que créer explicitement un fichier de
- correspondances de type fournit de meilleures performances
- que l'utilisation des MultiViews, car les informations
- nécessaires peuvent être simplement obtenues en lisant ce fichier, sans
- avoir à parcourir le répertoire à la recherche de types de fichiers.
Par conséquent, si la négociation de contenu est nécessaire pour votre
- site, préférez les fichiers de correspondances de type aux
- directives Options MultiViews pour mener à bien cette
- négociation. Se référer au document sur la
- Négociation de contenu pour une
- description complète des méthodes de négociation, et les instructions
- permettant de créer des fichiers de correspondances de type.
Dans les situations où Apache 2.x doit consulter le contenu d'un
- fichier en train d'être servi - par exemple à l'occasion du traitement
- d'une inclusion côté serveur - il transfère en général le fichier en
- mémoire si le système d'exploitation supporte une forme quelconque
- de mmap(2).
Sur certains systèmes, ce transfert en mémoire améliore les - performances. Dans certains cas, ce transfert peut toutefois les dégrader - et même diminuer la stabilité du démon httpd :
- -Dans certains systèmes d'exploitation, mmap devient
- moins efficace que read(2) quand le nombre de
- processeurs augmente. Sur les serveurs multiprocesseurs sous Solaris,
- par exemple, Apache 2.x sert parfois les fichiers consultés par le
- serveur plus rapidement quand mmap est désactivé.
Si vous transférez en mémoire un fichier localisé dans un système - de fichiers monté par NFS, et si un processus sur - une autre machine cliente NFS supprime ou tronque le fichier, votre - processus peut rencontrer une erreur de bus la prochaine fois qu'il - essaiera d'accéder au contenu du fichier en mémoire.
-Pour les installations où une de ces situations peut se produire,
- vous devez utiliser EnableMMAP off afin de désactiver le
- transfert en mémoire des fichiers servis. (Note : il est possible de
- passer outre cette directive au niveau de chaque répertoire.)
Dans les cas où Apache peut se permettre d'ignorer le contenu du
- fichier à servir - par exemple, lorsqu'il sert un contenu de fichier
- statique - il utilise en général le support sendfile du noyau si le
- système d'exploitation supporte l'opération sendfile(2).
Sur la plupart des plateformes, l'utilisation de sendfile améliore - les performances en éliminant les mécanismes de lecture et envoi séparés. - Dans certains cas cependant, l'utilisation de sendfile peut nuire à la - stabilité du démon httpd :
- -Certaines plateformes peuvent présenter un support de sendfile - défaillant que la construction du système n'a pas détecté, en - particulier si les binaires ont été construits sur une autre machine - et transférés sur la machine où le support de sendfile est - défaillant.
-Dans le cas des fichiers montés sous NFS, le noyau peut s'avérer - incapable de servir les fichiers réseau de manière fiable depuis - son propre cache.
-Pour les installations où une de ces situations peut se produire,
- vous devez utiliser EnableSendfile off afin de désactiver
- la mise à disposition de contenus de fichiers par sendfile. (Note : il
- est possible de passer outre cette directive au niveau de chaque
- répertoire.)
Avant Apache 1.3, les directives
- MinSpareServers,
- MaxSpareServers, et
- StartServers avaient des
- effets drastiques sur les performances de référence. En particulier,
- Apache avait besoin d'un délai de "montée en puissance" afin d'atteindre
- un nombre de processus enfants suffisant pour supporter la charge qui lui
- était appliquée. Après le lancement initial des processus enfants par
- StartServers, seulement un
- processus enfant par seconde était créé afin d'atteindre la valeur de la
- directive MinSpareServers. Ainsi,
- un serveur accédé par 100 clients simultanés et utilisant la valeur par
- défaut de 5 pour la directive
- StartServers, nécessitait
- environ 95 secondes pour lancer suffisamment de processus enfants
- permettant de faire face à la charge. Ceci fonctionne en pratique pour
- les serveurs en production, car ils sont rarement redémarrés. Ce n'est
- cependant pas le cas pour les tests de référence (benchmarks) où le
- serveur ne fonctionne que 10 minutes.
La règle "un processus par seconde" avait été implémentée afin
- d'éviter l'enlisement de la machine dans le démarrage de nouveaux
- processus enfants. Pendant que la machine est occupée à lancer des
- processus enfants, elle ne peut pas traiter les requêtes. Mais cette
- règle impactait tellement la perception des performances d'Apache qu'elle
- a dû être remplacée. A partir d'Apache 1.3, le code a assoupli la règle
- "un processus par seconde". Il va en lancer un, attendre une seconde,
- puis en lancer deux, attendre une seconde, puis en lancer quatre et
- ainsi de suite jusqu'à lancer 32 processus. Il s'arrêtera lorsque le
- nombre de processus aura atteint la valeur définie par la directive
- MinSpareServers.
Ceci s'avère suffisamment réactif pour pouvoir en général se passer
- de manipuler les valeurs des directives
- MinSpareServers,
- MaxSpareServers et
- StartServers. Lorsque plus de
- 4 processus enfants sont lancés par seconde, un message est émis vers
- le journal des erreurs. Si vous voyez apparaître souvent ce genre de
- message, vous devez vous pencher sur ces réglages. Pour vous guider,
- utilisez les informations délivrées par le module
- mod_status.
À mettre en relation avec la création de processus, leur destruction
- est définie par la valeur de la directive
- MaxRequestsPerChild. Sa valeur
- par défaut est 0, ce qui signifie qu'il n'y a pas de limite
- au nombre de requêtes q'un processus enfant peut traiter. Si votre
- configuration actuelle a cette directive réglée à une valeur très basse,
- de l'ordre de 30, il est conseillé de l'augmenter de manière
- significative. Si vous utilisez SunOs ou une ancienne version de Solaris,
- utilisez une valeur de l'ordre de 10000 à cause des fuites
- de mémoire.
Lorsqu'ils sont en mode "keep-alive", les processus enfants sont
- maintenus et ne font rien sinon attendre la prochaine requête sur la
- connexion déjà ouverte. La valeur par défaut de 5 de la
- directive KeepAliveTimeout tend à
- minimiser cet effet. Il faut trouver le bon compromis entre la bande
- passante réseau et les ressources du serveur. En aucun cas vous ne devez
- choisir une valeur supérieure à 60 seconds, car
-
- la plupart des bénéfices sont alors perdus.
Apache 2.x supporte les modèles simultanés enfichables, appelés
- Modules Multi-Processus (MPMs). Vous devez
- choisir un MPM au moment de la construction d'Apache. Certaines
- plateformes ont des modules MPM spécifiques :
- mpm_netware, et
- mpm_winnt. Sur les systèmes de type Unix, vous avez le
- choix entre un grand nombre de modules MPM. Le choix du MPM peut affecter
- la vitesse et l'évolutivité du démon httpd :
worker utilise plusieurs processus
- enfants possédant chacun de nombreux threads. Chaque thread gère une
- seule connexion à la fois. Worker est en général un bon choix pour les
- serveurs présentant un traffic important car il possède une empreinte
- mémoire plus petite que le MPM prefork.prefork utilise plusieurs processus enfants
- possédant chacun un seul thread. Chaque processus gère une seule
- connexion à la fois. Sur de nombreux systèmes, prefork est comparable
- en matière de vitesse à worker, mais il utilise plus de mémoire. De par
- sa conception sans thread, prefork présente des avantages par rapport à
- worker dans certaines situations : il peut être utilisé avec les
- modules tiers qui ne supportent pas le threading, et son débogage est plus
- aisé sur les platesformes présentant un support du débogage des threads
- rudimentaire.Pour plus d'informations sur ces deux MPMs et les autres, veuillez - vous référer à la documentation sur les - MPM.
- - - -Comme le contrôle de l'utilisation de la mémoire est très important
- en matière de performance, il est conseillé d'éliminer les modules que
- vous n'utilisez pas vraiment. Si vous avez construit ces modules en
- tant que DSOs, leur élimination consiste
- simplement à commenter la directive
- LoadModule associée à ce
- module. Ceci vous permet de vérifier si votre site fonctionne toujours
- après la suppression de tel ou tel module.
Par contre, si les modules que vous voulez supprimer sont liés - statiquement à votre binaire Apache, vous devrez recompiler ce dernier - afin de pouvoir les éliminer.
- -La question qui découle de ce qui précède est évidemment de
- savoir de quels modules vous avez besoin et desquels vous pouvez vous
- passer. La réponse sera bien entendu différente d'un site web à
- l'autre. Cependant, la liste minimale de modules nécessaire à
- la survie de votre site contiendra certainement
- mod_mime, mod_dir et
- mod_log_config. mod_log_config est bien
- entendu optionnel puisque vous pouvez faire fonctionner un site web
- en se passant de fichiers journaux ; ceci est cependant
- déconseillé.
Certains modules, à l'instar de mod_cache et des
- versions de développement récentes du MPM worker, utilisent l'API
- atomique d'APR. Cette API propose des opérations atomiques que l'on
- peut utiliser pour alléger la synchronisation des threads.
Par défaut, APR implémente ces opérations en utilisant les
- mécanismes les plus efficaces disponibles sur chaque plateforme cible
- (Système d'exploitation et processeur). De nombreux processeurs modernes,
- par exemple, possèdent une instruction qui effectue une opération
- atomique de type comparaison et échange ou compare-and-swap (CAS) au
- niveau matériel. Sur certaines platesformes cependant, APR utilise par
- défaut une implémentation de l'API atomique plus lente, basée sur les
- mutex, afin d'assurer la compatibilité avec les anciens modèles de
- processeurs qui ne possèdent pas ce genre d'instruction. Si vous
- construisez Apache pour une de ces platesformes, et ne prévoyez de
- l'exécuter que sur des processeurs récents, vous pouvez sélectionner une
- implémentation atomique plus rapide à la compilation en utilisant
- l'option --enable-nonportable-atomics du
- script configure :
- ./buildconf
- ./configure --with-mpm=worker --enable-nonportable-atomics=yes
-
L'option --enable-nonportable-atomics concerne les
- platesformes suivantes :
--enable-nonportable-atomics au script configure, APR
- génère un code qui utilise le code opération SPARC v8plus pour des
- opérations de compare-and-swap matériel plus rapides. Si vous
- utilisez cette option de configure avec Apache, les opérations
- atomiques seront plus efficaces (permettant d'alléger la charge du
- processeur et un plus haut niveau de simultanéité), mais
- l'exécutable produit ne fonctionnera que sur les processeurs
- UltraSPARC.
- --enable-nonportable-atomics au script configure,
- APR générera un code qui utilise un code d'opération du 486
- pour des opérations de compare-and-swap matériel plus rapides. Le
- code résultant est plus efficace en matière d'opérations atomiques,
- mais l'exécutable produit ne fonctionnera que sur des processeurs
- 486 et supérieurs (et non sur des 386).
- Si vous incluez le module mod_status à la
- construction d'Apache et ajoutez ExtendedStatus On à sa
- configuration, Apache va effectuer pour chaque requête deux appels à
- gettimeofday(2) (ou times(2) selon votre
- système d'exploitation), et (pour les versions antérieures à 1.3) de
- nombreux appels supplémentaires à time(2). Tous ces
- appels sont effectués afin que le rapport de statut puisse contenir
- des indications temporelles. Pour améliorer les performances, utilisez
- ExtendedStatus off (qui est le réglage par défaut).
Cette section n'a pas été totalement mise à jour car elle ne tient pas - compte des changements intervenus dans la version 2.x du Serveur HTTP - Apache. Certaines informations sont encore pertinentes, il vous est - cependant conseillé de les utiliser avec prudence.
-Ce qui suit est une brève discussion à propos de l'API des sockets
- Unix. Supposons que votre serveur web utilise plusieurs directives
- Listen afin d'écouter
- plusieurs ports ou de multiples adresses. Afin de tester chaque socket
- pour voir s'il a une connexion en attente, Apache utilise
- select(2). select(2) indique si un socket a
- zéro ou au moins une connexion en attente. Le modèle
- d'Apache comporte plusieurs processus enfants, et tous ceux qui sont
- inactifs testent la présence de nouvelles connexions au même moment.
- Une implémentation rudimentaire de ceci pourrait ressembler à
- l'exemple suivant
- (ces exemples ne sont pas extraits du code d'Apache, ils ne sont
- proposés qu'à des fins pédagogiques) :
- for (;;) {
-
- for (;;) {
-
- fd_set accept_fds;
-
- FD_ZERO (&accept_fds);
- for (i = first_socket; i <= last_socket; ++i) {
-
- FD_SET (i, &accept_fds);
-
- }
- rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
- if (rc < 1) continue;
- new_connection = -1;
- for (i = first_socket; i <= last_socket; ++i) {
-
- if (FD_ISSET (i, &accept_fds)) {
-
- new_connection = accept (i, NULL, NULL);
- if (new_connection != -1) break;
-
- }
-
- }
- if (new_connection != -1) break;
-
- }
- process the new_connection;
-
- }
-
Mais cette implémentation rudimentaire présente une sérieuse lacune.
- Rappelez-vous que les processus enfants exécutent cette boucle au même
- moment ; ils vont ainsi bloquer sur select s'ils se trouvent
- entre deux requêtes. Tous ces processus bloqués vont se réactiver et
- sortir de select quand une requête va apparaître sur un des
- sockets (le nombre de processus enfants qui se réactivent varie en
- fonction du système d'exploitation et des réglages de synchronisation).
- Ils vont alors tous entrer dans la boucle et tenter un
- "accept" de la connexion. Mais seulement un d'entre eux y
- parviendra (en supposant qu'il ne reste q'une seule connexion en
- attente), les autres vont se bloquer au niveau de accept.
- Ceci verrouille vraiment ces processus de telle sorte qu'ils ne peuvent
- plus servir de requêtes que par cet unique socket, et il en sera ainsi
- jusqu'à ce que suffisamment de nouvelles requêtes apparaissent sur ce
- socket pour les réactiver tous. Cette lacune a été documentée pour la
- première fois dans
- PR#467. Il existe
- au moins deux solutions.
La première consiste à rendre les sockets non blocants. Dans ce cas,
- accept ne bloquera pas les processus enfants, et ils
- pourront continuer à s'exécuter immédiatement. Mais ceci consomme des
- ressources processeur. Supposons que vous ayez dix processus enfants
- inactifs dans select, et qu'une connexion arrive.
- Neuf des dix processus vont se réactiver, tenter un accept
- de la connexion, échouer, et boucler dans select, tout en
- n'ayant finalement rien accompli. Pendant ce temps, aucun de ces processus
- ne traite les requêtes qui arrivent sur d'autres sockets jusqu'à ce
- qu'ils retournent dans select. Finalement, cette solution
- ne semble pas très efficace, à moins que vous ne disposiez d'autant de
- processeurs inactifs (dans un serveur multiprocesseur) que de processus
- enfants inactifs, ce qui n'est pas une situation très courante.
Une autre solution, celle qu'utilise Apache, consiste à sérialiser les - entrées dans la boucle interne. La boucle ressemble à ceci (les - différences sont mises en surbrillance) :
- -
- for (;;) {
-
- accept_mutex_on ();
- for (;;) {
-
- fd_set accept_fds;
-
- FD_ZERO (&accept_fds);
- for (i = first_socket; i <= last_socket; ++i) {
-
- FD_SET (i, &accept_fds);
-
- }
- rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
- if (rc < 1) continue;
- new_connection = -1;
- for (i = first_socket; i <= last_socket; ++i) {
-
- if (FD_ISSET (i, &accept_fds)) {
-
- new_connection = accept (i, NULL, NULL);
- if (new_connection != -1) break;
-
- }
-
- }
- if (new_connection != -1) break;
-
- }
- accept_mutex_off ();
- process the new_connection;
-
- }
-
Les fonctions
- accept_mutex_on et accept_mutex_off
- implémentent un sémaphore permettant une exclusion mutuelle. Un seul
- processus enfant à la fois peut posséder le mutex. Plusieurs choix se
- présentent pour implémenter ces mutex. Ce choix est défini dans
- src/conf.h (versions antérieures à 1.3) ou
- src/include/ap_config.h (versions 1.3 ou supérieures).
- Certaines architectures ne font pas ce choix du mode de verrouillage ;
- l'utilisation de directives
- Listen multiples sur ces
- architectures est donc peu sûr.
On peut utiliser la directive
- AcceptMutex pour modifier
- l'implémentation du mutex sélectionnée à l'exécution.
AcceptMutex flockCette méthode utilise l'appel système flock(2) pour
- créer un fichier verrou (dont la localisation est définie par la
- directive LockFile.
AcceptMutex fcntlCette méthode utilise l'appel système fcntl(2) pour
- créer un fichier verrou ((dont la localisation est définie par la
- directive LockFile.
AcceptMutex sysvsem(Versions 1.3 ou supérieures) Cette méthode utilise les sémaphores
- style SysV pour implémenter les mutex. Malheureusement, les
- sémaphores style SysV ont quelques effets de bord néfastes. L'un
- d'entre eux est la possibilité pour Apache de s'arrêter sans
- "faire le ménage" dans les sémaphores (voir la page de manuel de
- ipcs(8)). Un autre effet de bord est introduit par
- l'API des sémaphores qui permet à tout CGI s'exécutant sous le même
- uid que le serveur web d'effectuer une attaque par déni de service
- (c'est à dire tous les CGIs, à moins que vous n'utilisiez
- un programme comme suexec ou
- cgiwrapper)..
AcceptMutex pthread(versions 1.3 ou supérieures) Cette méthode utilise les mutex - POSIX et devrait fonctionner sur toute architecture implémentant - de manière complète la spécification concernant les threads POSIX ; - il semble cependant qu'elle ne fonctionne que sur Solaris (versions - 2.5 ou supérieures), et sous certaines configurations seulement. Si - vous tentez l'expérience, votre serveur risque de se bloquer et de ne - plus répondre à vos sollicitations. Par contre, les serveurs - n'hébergeant que du contenu statique devraient fonctionner - correctement.
-AcceptMutex posixsem(Versions 2.0 ou supérieures) Cette méthode utilise les sémaphores - POSIX. L'appartenance du sémaphore n'est pas récupérée quand un - thread du processus qui détient le mutex provoque une erreur de - segmentation, ce qui a pour effet de bloquer le serveur.
-Si votre système propose une méthode de sérialisation différente de - celles de la liste ci-dessus, il pourrait être intéressant d'ajouter à - APR le code correspondant.
- -Une autre solution qui a été imaginée mais jamais implémentée, consiste - à sérialiser partiellement la boucle -- c'est à dire y faire entrer un - certain nombre de processus. Ceci ne présenterait un intérêt que sur les - machines multiprocesseurs où plusieurs processus enfants peuvent - s'exécuter simultanément, et encore, la sérialisation ne tire pas - vraiment parti de toute la bande passante. C'est une possibilité - d'investigation future, mais demeure de priorité basse car les serveurs - web à architecture hautement parallèle ne sont pas la norme.
- -Pour bien faire, vous devriez faire fonctionner votre serveur sans
- directives Listen multiples
- si vous visez les performances les plus élevées.
- Mais lisez ce qui suit.
Ce qui précède convient pour les serveurs à sockets multiples, mais
- qu'en est-il des serveurs à socket unique ? En théorie, ils ne
- devraient pas rencontrer les mêmes problèmes car tous les processus
- enfants peuvent se bloquer dans accept(2) jusqu'à ce qu'une
- connexion arrive, et ils ne sont pas utilisés à ne rien faire. En
- pratique, ceci dissimule un même comportement de bouclage
- discuté plus haut dans la solution non-blocante. De la manière dont
- sont implémentées les piles TCP, le noyau réactive véritablement tous les
- processus bloqués dans accept quand une seule connexion
- arrive. Un de ces processus prend la connexion en compte et retourne
- dans l'espace utilisateur, les autres bouclant dans l'espace du
- noyau et se désactivant quand ils s'aperçoivent qu'il n'y a pas de
- connexion pour eux. Ce bouclage est invisible depuis le code de l'espace
- utilisateur, mais il est quand-même présent. Ceci peut conduire à la
- même augmentation de charge à perte que la solution non blocante au cas
- des sockets multiples peut induire.
Pour cette raison, il apparaît que de nombreuses architectures se
- comportent plus "proprement" si on sérialise même dans le cas d'une socket
- unique. Il s'agit en fait du comportement par défaut dans la plupart des
- cas. Des expériences poussées sous Linux (noyau 2.0.30 sur un
- biprocesseur Pentium pro 166 avec 128 Mo de RAM) ont montré que la
- sérialisation d'une socket unique provoque une diminution inférieure à 3%
- du nombre de requêtes par secondes par rapport au traitement non
- sérialisé. Mais le traitement non sérialisé des sockets uniques induit
- un temps de réponse supplémentaire de 100 ms pour chaque requête. Ce
- temps de réponse est probablement provoqué par une limitation sur les
- lignes à haute charge, et ne constitue un problème que sur les réseaux
- locaux. Si vous voulez vous passer de la sérialisation des sockets
- uniques, vous pouvez définir
- SINGLE_LISTEN_UNSERIALIZED_ACCEPT et les
- serveurs à socket unique ne pratiqueront plus du tout la
- sérialisation.
Comme discuté dans - draft-ietf-http-connection-00.txt section 8, pour implémenter de - manière fiable le protocole, un serveur HTTP doit fermer - les deux directions d'une communication indépendamment (rappelez-vous - qu'une connexion TCP est bidirectionnelle, chaque direction étant - indépendante de l'autre). Ce fait, souvent ignoré par les autres - serveurs, est implémenté correctement dans Apache depuis la - version 1.2.
- -Quand cette fonctionnalité fut ajoutée à Apache, elle causa une
- avalanche de problèmes sur plusieurs versions d'Unix à cause d'une
- implémentation à courte vue. La spécification TCP ne précise pas que
- l'état FIN_WAIT_2 possède un temps de réponse mais elle ne
- l'exclut pas. Sur les systèmes qui n'introduisent pas ce temps de
- réponse, Apache 1.2 induit de nombreux blocages définitifs de socket
- dans l'état FIN_WAIT_2. On peut eviter ceci dans de nombreux
- cas tout simplement en mettant à jour TCP/IP avec le dernier patch mis à
- disposition par le fournisseur. Dans les cas où le fournisseur n'a
- jamais fourni de patch (par exemple, SunOS4 -- bien que les utilisateurs
- possédant une license source puissent le patcher eux-mêmes), nous avons
- décidé de désactiver cette fonctionnalité.
Il y a deux méthodes pour arriver à ce résultat. La première est
- l'option de socket SO_LINGER. Mais le sort a voulu que cette
- solution ne soit jamais implémentée correctement dans la plupart des
- piles TCP/IP. Et même dans les rares cas où cette solution a été
- implémentée correctement (par exemple Linux 2.0.31), elle se
- montre beaucoup plus gourmande (en temps processeur) que la solution
- suivante.
Pour la plus grande partie, Apache implémente cette solution à l'aide
- d'une fonction appelée lingering_close (définie dans
- http_main.c). La fonction ressemble approximativement à
- ceci :
- void lingering_close (int s)
- {
-
- char junk_buffer[2048];
-
- /* shutdown the sending side */
- shutdown (s, 1);
-
- signal (SIGALRM, lingering_death);
- alarm (30);
-
- for (;;) {
-
- select (s for reading, 2 second timeout);
- if (error) break;
- if (s is ready for reading) {
-
- if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {
-
- break;
-
- }
- /* just toss away whatever is here */
-
- }
-
- }
-
- close (s);
-
- }
-
Ceci ajoute naturellement un peu de charge à la fin d'une connexion,
- mais s'avère nécessaire pour une implémentation fiable. Comme HTTP/1.1
- est de plus en plus présent et que toutes les connexions sont
- persistentes, la charge sera amortie par la multiplicité des requêtes.
- Si vous voulez jouer avec le feu en désactivant cette fonctionnalité,
- vous pouvez définir NO_LINGCLOSE, mais c'est fortement
- déconseillé. En particulier, comme les connexions persistantes en
- pipeline de HTTP/1.1 commencent à être utilisées,
- lingering_close devient une absolue nécessité (et les
-
- connexions en pipeline sont plus rapides ; vous avez donc tout
- intérêt à les supporter).
Les processus parent et enfants d'Apache communiquent entre eux à
- l'aide d'un objet appelé "Tableau de bord" (Scoreboard). Idéalement, cet
- échange devrait s'effectuer en mémoire partagée. Pour les systèmes
- d'exploitation auxquels nous avons eu accès, ou pour lesquels nous avons
- obtenu des informations suffisamment détaillées pour effectuer un
- portage, cet échange est en général implémenté en utilisant la mémoire
- partagée. Pour les autres, on utilise par défaut un fichier d'échange sur
- disque. Le fichier d'échange sur disque est non seulement lent, mais
- aussi peu fiable (et propose moins de fonctionnalités). Recherchez dans
- le fichier src/main/conf.h correspondant à votre
- architecture soit USE_MMAP_SCOREBOARD, soit
- USE_SHMGET_SCOREBOARD. La définition de l'un des deux
- (ainsi que leurs compagnons respectifs HAVE_MMAP et
- HAVE_SHMGET), active le code fourni pour la mémoire
- partagée. Si votre système propose une autre solution pour la gestion de
- la mémoire partagée, éditez le fichier src/main/http_main.c
- et ajoutez la portion de code nécessaire pour pouvoir l'utiliser dans
- Apache (Merci de nous envoyer aussi le patch correspondant).
Si vous n'avez pas l'intention d'utiliser les modules chargés
- dynamiquement (ce qui est probablement le cas si vous êtes en train de
- lire ce document afin de personnaliser votre serveur en recherchant le
- moindre des gains en performances), vous pouvez ajouter la définition
- -DDYNAMIC_MODULE_LIMIT=0 à la construction de votre serveur.
- Ceci aura pour effet de libérer la mémoire RAM allouée pour le
- chargement dynamique des modules.
Voici la trace d'un appel système d'Apache 2.0.38 avec le MPM worker - sous Solaris 8. Cette trace a été collectée à l'aide de la commande :
- -
- truss -l -p httpd_child_pid.
-
L'option -l demande à truss de tracer l'ID du LWP
- (lightweight process--la version de Solaris des threads niveau noyau) qui
- invoque chaque appel système.
Les autres systèmes peuvent proposer des utilitaires de traçage
- des appels système différents comme strace,
- ktrace, ou par. Ils produisent cependant tous une
- trace similaire.
Dans cette trace, un client a demandé un fichier statique de 10 ko au - démon httpd. Le traçage des requêtes pour des contenus non statiques - ou comportant une négociation de contenu a une présentation - différente (et même assez laide dans certains cas).
- -/67: accept(3, 0x00200BEC, 0x00200C0C, 1) (sleeping...) -/67: accept(3, 0x00200BEC, 0x00200C0C, 1) = 9
Dans cette trace, le thread à l'écoute s'exécute à l'intérieur de - LWP #67.
- -accept(2). Sur
- cette plateforme spécifique, le MPM worker utilise un accept non sérialisé
- par défaut sauf s'il est en écoute sur des ports multiples./65: lwp_park(0x00000000, 0) = 0 -/67: lwp_unpark(65, 1) = 0
Après avoir accepté la connexion, le thread à l'écoute réactive un - thread du worker pour effectuer le traitement de la requête. Dans cette - trace, le thread du worker qui traite la requête est associé à - LWP #65.
- -/65: getsockname(9, 0x00200BA4, 0x00200BC4, 1) = 0
Afin de pouvoir implémenter les hôtes virtuels, Apache doit connaître
- l'adresse du socket local utilisé pour accepter la connexion. On pourrait
- supprimer cet appel dans de nombreuses situations (par exemple dans le cas
- où il n'y a pas d'hôte virtuel ou dans le cas où les directives
- Listen contiennent des adresses
- sans caractères de substitution). Mais aucun effort n'a été accompli à ce
- jour pour effectuer ces optimisations.
/65: brk(0x002170E8) = 0 -/65: brk(0x002190E8) = 0
L'appel brk(2) alloue de la mémoire dans le tas. Ceci est
- rarement visible dans une trace d'appel système, car le démon httpd
- utilise des allocateurs mémoire de son cru (apr_pool et
- apr_bucket_alloc) pour la plupart des traitements de requêtes.
- Dans cette trace, le démon httpd vient juste de démarrer, et il doit
- appeler malloc(3) pour réserver les blocs de mémoire
- nécessaires à la création de ses propres allocateurs de mémoire.
/65: fcntl(9, F_GETFL, 0x00000000) = 2 -/65: fstat64(9, 0xFAF7B818) = 0 -/65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B910, 2190656) = 0 -/65: fstat64(9, 0xFAF7B818) = 0 -/65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B914, 2190656) = 0 -/65: setsockopt(9, 65535, 8192, 0xFAF7B918, 4, 2190656) = 0 -/65: fcntl(9, F_SETFL, 0x00000082) = 0
Ensuite, le thread de worker passe la connexion du client (descripteur
- de fichier 9) en mode non blocant. Les appels setsockopt(2)
- et getsockopt(2) constituent un effet de bord de la manière
- dont la libc de Solaris utilise fcntl(2) pour les sockets.
/65: read(9, " G E T / 1 0 k . h t m".., 8000) = 97
Le thread de worker lit la requête du client.
- -/65: stat("/var/httpd/apache/httpd-8999/htdocs/10k.html", 0xFAF7B978) = 0
-/65: open("/var/httpd/apache/httpd-8999/htdocs/10k.html", O_RDONLY) = 10Ce démon httpd a été configuré avec les options
- Options FollowSymLinks et AllowOverride None. Il
- n'a donc ni besoin d'appeler lstat(2) pour chaque répertoire
- du chemin du fichier demandé, ni besoin de vérifier la présence de fichiers
- .htaccess. Il appelle simplement stat(2) pour
- vérifier d'une part que le fichier existe, et d'autre part que c'est un
- fichier régulier, et non un répertoire.
/65: sendfilev(0, 9, 0x00200F90, 2, 0xFAF7B53C) = 10269
Dans cet exemple, le démon httpd peut envoyer l'en-tête de la réponse
- HTTP et le fichier demandé à l'aide d'un seul appel système
- sendfilev(2). La sémantique de sendfile varie en fonction des
- systèmes d'exploitation. Sur certains autres systèmes, il faut faire un
- appel à write(2) ou writev(2) pour envoyer les
- en-têtes avant d'appeler sendfile(2).
/65: write(4, " 1 2 7 . 0 . 0 . 1 - ".., 78) = 78
Cet appel à write(2) enregistre la requête dans le journal
- des accès. Notez qu'une des choses manquant à cette trace est un appel à
- time(2). A la différence d'Apache 1.3, Apache 2.x utilise
- gettimeofday(3) pour consulter l'heure. Sur certains systèmes
- d'exploitation, comme Linux ou Solaris, gettimeofday est
- implémenté de manière optimisée de telle sorte qu'il consomme moins de
- ressources qu'un appel système habituel.
/65: shutdown(9, 1, 1) = 0 -/65: poll(0xFAF7B980, 1, 2000) = 1 -/65: read(9, 0xFAF7BC20, 512) = 0 -/65: close(9) = 0
Le thread de worker effectue une fermeture "en prenant son temps" - (lingering close) de la connexion.
- -/65: close(10) = 0 -/65: lwp_park(0x00000000, 0) (sleeping...)
Enfin, le thread de worker ferme le fichier qu'il vient de délivrer et - se bloque jusqu'à ce que le thread en écoute lui assigne une autre - connexion.
- -/67: accept(3, 0x001FEB74, 0x001FEB94, 1) (sleeping...)
Pendant ce temps, le thread à l'écoute peut accepter une autre connexion
- à partir du moment où il a assigné la connexion présente à un thread de
- worker (selon une certaine logique de contrôle de flux dans le MPM worker
- qui impose des limites au thread à l'écoute si tous les threads de worker
- sont occupés). Bien que cela n'apparaisse pas dans cette trace,
- l'accept(2) suivant peut (et le fait en général, en situation
- de charge élevée) s'exécuter en parallèle avec le traitement de la
- connexion qui vient d'être acceptée par le thread de worker.
Serveur Apache HTTP Version 2.3
+Apache 2.x est un serveur web à usage général, conçu dans un but + d'équilibre entre souplesse, portabilité et performances. Bien que non + conçu dans le seul but d'établir une référence en la matière, + Apache 2.x est capable de hautes performances dans de nombreuses situations + du monde réel.
+ +Comparée à Apache 1.3, la version 2.x comporte de nombreuses + optimisations supplémentaires permettant d'améliorer le débit du serveur + et sa personnalisation. La plupart de ces améliorations sont activées par + défaut. Cependant, certains choix de configuration à la compilation et à + l'exécution peuvent affecter les performances de manière significative. Ce + document décrit les options qu'un administrateur de serveur peut configurer + pour améliorer les performances d'une installation d'Apache 2.x. Certaines + de ces options de configuration permettent au démon httpd de mieux tirer + parti des possibilités du matériel et du système d'exploitation, tandis + que d'autres permettent à l'administrateur de privilégier la vitesse + par rapport aux fonctionnalités.
+ +Le principal problème matériel qui affecte les performances du serveur
+ web est la mémoire vive (RAM). Un serveur web ne devrait jamais avoir à
+ utiliser le swap, car le swapping augmente le temps de réponse de chaque
+ requête au delà du point que les utilisateurs considèrent comme
+ "trop lent". Ceci incite les utilisateurs à cliquer sur "Stop", puis
+ "Charger à nouveau", ce qui a pour effet d'augmenter encore la charge
+ du serveur. Vous pouvez, et même devez définir la valeur de la directive
+ MaxClients de façon à ce que
+ votre serveur ne lance pas un nombre de processus enfants tel qu'il
+ commence à faire du swapping. La méthode pour y parvenir est
+ simple : déterminez la taille de votre processus Apache standard en
+ consultant votre liste de processus à l'aide d'un outil tel que
+ top, et divisez votre quantité totale de mémoire disponible
+ par cette taille, tout en gardant un espace suffisant
+ pour les autres processus.
Hormis ce réglage relatif à la mémoire, le reste est trivial : le + processeur, la carte réseau et les disques doivent être suffisamment + rapides, où "suffisamment rapide" doit être déterminé par + l'expérience.
+ +Le choix du système d'exploitation dépend principalement du + contexte local. Voici cependant quelques conseils qui se sont + généralement avérés utiles :
+ +Exécutez la dernière version stable et le niveau de patches le + plus haut du système d'exploitation que vous avez choisi. De nombreux + éditeurs de systèmes d'exploitation ont amélioré de manière + significative les performances de leurs piles TCP et de leurs + bibliothèques de thread ces dernières années.
+Si votre système d'exploitation possède un appel système
+ sendfile(2), assurez-vous d'avoir installé la version
+ et/ou les patches nécessaires à son activation. (Pour Linux, par
+ exemple, cela se traduit par Linux 2.4 ou plus. Pour les versions
+ anciennes de Solaris 8, vous pouvez être amené à appliquer un patch.)
+ Sur les systèmes où il est disponible, sendfile permet
+ à Apache 2 de servir les contenus statiques plus rapidement, tout en
+ induisant une charge CPU inférieure.
| Modules Apparentés | Directives Apparentées |
|---|---|
Avant Apache 1.3, la directive
+ HostnameLookups était positionnée
+ par défaut à On. Ce réglage augmente le temps de réponse de
+ chaque requête car il entraîne une recherche DNS et le traitement de la
+ requête ne pourra pas être achevé tant que cette recherche ne sera
+ pas terminée. Avec Apache 1.3, ce réglage est défini par défaut à
+ Off. Si vous souhaitez que les adresses dans vos fichiers
+ journaux soient résolues en noms d'hôtes, utilisez le programme
+ logresolve fourni avec Apache, ou un des nombreux
+ paquets générateurs de rapports sur les journaux disponibles.
Il est recommandé d'effectuer ce genre de traitement a posteriori + de vos fichiers journaux sur une autre machine que celle qui héberge le + serveur web en production, afin que cette activité n'affecte pas les + performances du serveur.
+ +Si vous utilisez une directive
+ Allowfrom domainDeny from domain
Notez qu'il est possible de modifier la portée des directives, en les
+ plaçant par exemple à l'intérieur d'une section
+ <Location /server-status>. Les recherches DNS ne
+ seront alors effectuées que pour les requêtes qui satisfont aux critères.
+ Voici un exemple qui désactive les recherches DNS sauf pour les fichiers
+ .html et .cgi :
+ HostnameLookups off
+ <Files ~ "\.(html|cgi)$">
+
+ HostnameLookups on
+
+ </Files>
+
Mais même dans ce cas, si vous n'avez besoin de noms DNS que dans
+ certains CGIs, vous pouvez effectuer l'appel à gethostbyname
+ dans les CGIs spécifiques qui en ont besoin.
Chaque fois que la ligne Options FollowSymLinks sera
+ absente, ou que la ligne Options SymLinksIfOwnerMatch sera
+ présente dans votre espace d'adressage, Apache devra effectuer des
+ appels système supplémentaires pour vérifier la présence de liens
+ symboliques. Un appel supplémentaire par élément du chemin du fichier.
+ Par exemple, si vous avez :
+ DocumentRoot /www/htdocs
+ <Directory />
+
+ Options SymLinksIfOwnerMatch
+
+ </Directory>
+
et si une requête demande l'URI /index.html, Apache
+ effectuera un appel à lstat(2) pour
+ /www, /www/htdocs, et
+ /www/htdocs/index.html. Les résultats de ces appels à
+ lstat ne sont jamais mis en cache, ils devront donc être
+ générés à nouveau pour chaque nouvelle requête. Si vous voulez absolument
+ vérifier la sécurité des liens symboliques, vous pouvez utiliser une
+ configuration du style :
+ DocumentRoot /www/htdocs
+ <Directory />
+
+ Options FollowSymLinks
+
+ </Directory>
+
+ <Directory /www/htdocs>
+
+ Options -FollowSymLinks +SymLinksIfOwnerMatch
+
+ </Directory>
+
Ceci évite au moins les vérifications supplémentaires pour le chemin
+ défini par DocumentRoot. Notez que
+ vous devrez ajouter des sections similaires si vous avez des chemins
+ définis par les directives
+ Alias ou
+ RewriteRule en dehors de
+ la racine de vos documents. Pour améliorer les performances, et supprimer
+ toute protection des liens symboliques, ajoutez l'option
+ FollowSymLinks partout, et n'utilisez jamais l'option
+ SymLinksIfOwnerMatch.
Dans toute partie de votre espace d'adressage où vous autoriserez
+ la surcharge de la configuration (en général à l'aide de fichiers
+ .htaccess), Apache va tenter d'ouvrir .htaccess
+ pour chaque élément du chemin du fichier demandé. Par exemple, si vous
+ avez :
+ DocumentRoot /www/htdocs
+ <Directory />
+
+ AllowOverride all
+
+ </Directory>
+
et qu'une requête demande l'URI /index.html, Apache
+ tentera d'ouvrir /.htaccess, /www/.htaccess,
+ et /www/htdocs/.htaccess. Les solutions sont similaires à
+ celles évoquées précédemment pour Options FollowSymLinks.
+ Pour améliorer les performances, utilisez AllowOverride None
+ pour tous les niveaux de votre espace d'adressage.
Dans la mesure du possible, évitez toute négociation de contenu si + vous tenez au moindre gain en performances. En pratique toutefois, + les bénéfices de la négociation l'emportent souvent sur la diminution + des performances. + Il y a cependant un cas dans lequel vous pouvez accélérer le serveur. + Au lieu d'utiliser une directive générique comme :
+ +
+ DirectoryIndex index
+
utilisez une liste explicite d'options :
+ +
+ DirectoryIndex index.cgi index.pl index.shtml index.html
+
où vous placez le choix courant en première position.
+ +Notez aussi que créer explicitement un fichier de
+ correspondances de type fournit de meilleures performances
+ que l'utilisation des MultiViews, car les informations
+ nécessaires peuvent être simplement obtenues en lisant ce fichier, sans
+ avoir à parcourir le répertoire à la recherche de types de fichiers.
Par conséquent, si la négociation de contenu est nécessaire pour votre
+ site, préférez les fichiers de correspondances de type aux
+ directives Options MultiViews pour mener à bien cette
+ négociation. Se référer au document sur la
+ Négociation de contenu pour une
+ description complète des méthodes de négociation, et les instructions
+ permettant de créer des fichiers de correspondances de type.
Dans les situations où Apache 2.x doit consulter le contenu d'un
+ fichier en train d'être servi - par exemple à l'occasion du traitement
+ d'une inclusion côté serveur - il transfère en général le fichier en
+ mémoire si le système d'exploitation supporte une forme quelconque
+ de mmap(2).
Sur certains systèmes, ce transfert en mémoire améliore les + performances. Dans certains cas, ce transfert peut toutefois les dégrader + et même diminuer la stabilité du démon httpd :
+ +Dans certains systèmes d'exploitation, mmap devient
+ moins efficace que read(2) quand le nombre de
+ processeurs augmente. Sur les serveurs multiprocesseurs sous Solaris,
+ par exemple, Apache 2.x sert parfois les fichiers consultés par le
+ serveur plus rapidement quand mmap est désactivé.
Si vous transférez en mémoire un fichier localisé dans un système + de fichiers monté par NFS, et si un processus sur + une autre machine cliente NFS supprime ou tronque le fichier, votre + processus peut rencontrer une erreur de bus la prochaine fois qu'il + essaiera d'accéder au contenu du fichier en mémoire.
+Pour les installations où une de ces situations peut se produire,
+ vous devez utiliser EnableMMAP off afin de désactiver le
+ transfert en mémoire des fichiers servis. (Note : il est possible de
+ passer outre cette directive au niveau de chaque répertoire.)
Dans les cas où Apache peut se permettre d'ignorer le contenu du
+ fichier à servir - par exemple, lorsqu'il sert un contenu de fichier
+ statique - il utilise en général le support sendfile du noyau si le
+ système d'exploitation supporte l'opération sendfile(2).
Sur la plupart des plateformes, l'utilisation de sendfile améliore + les performances en éliminant les mécanismes de lecture et envoi séparés. + Dans certains cas cependant, l'utilisation de sendfile peut nuire à la + stabilité du démon httpd :
+ +Certaines plateformes peuvent présenter un support de sendfile + défaillant que la construction du système n'a pas détecté, en + particulier si les binaires ont été construits sur une autre machine + et transférés sur la machine où le support de sendfile est + défaillant.
+Dans le cas des fichiers montés sous NFS, le noyau peut s'avérer + incapable de servir les fichiers réseau de manière fiable depuis + son propre cache.
+Pour les installations où une de ces situations peut se produire,
+ vous devez utiliser EnableSendfile off afin de désactiver
+ la mise à disposition de contenus de fichiers par sendfile. (Note : il
+ est possible de passer outre cette directive au niveau de chaque
+ répertoire.)
Avant Apache 1.3, les directives
+ MinSpareServers,
+ MaxSpareServers, et
+ StartServers avaient des
+ effets drastiques sur les performances de référence. En particulier,
+ Apache avait besoin d'un délai de "montée en puissance" afin d'atteindre
+ un nombre de processus enfants suffisant pour supporter la charge qui lui
+ était appliquée. Après le lancement initial des processus enfants par
+ StartServers, seulement un
+ processus enfant par seconde était créé afin d'atteindre la valeur de la
+ directive MinSpareServers. Ainsi,
+ un serveur accédé par 100 clients simultanés et utilisant la valeur par
+ défaut de 5 pour la directive
+ StartServers, nécessitait
+ environ 95 secondes pour lancer suffisamment de processus enfants
+ permettant de faire face à la charge. Ceci fonctionne en pratique pour
+ les serveurs en production, car ils sont rarement redémarrés. Ce n'est
+ cependant pas le cas pour les tests de référence (benchmarks) où le
+ serveur ne fonctionne que 10 minutes.
La règle "un processus par seconde" avait été implémentée afin
+ d'éviter l'enlisement de la machine dans le démarrage de nouveaux
+ processus enfants. Pendant que la machine est occupée à lancer des
+ processus enfants, elle ne peut pas traiter les requêtes. Mais cette
+ règle impactait tellement la perception des performances d'Apache qu'elle
+ a dû être remplacée. A partir d'Apache 1.3, le code a assoupli la règle
+ "un processus par seconde". Il va en lancer un, attendre une seconde,
+ puis en lancer deux, attendre une seconde, puis en lancer quatre et
+ ainsi de suite jusqu'à lancer 32 processus. Il s'arrêtera lorsque le
+ nombre de processus aura atteint la valeur définie par la directive
+ MinSpareServers.
Ceci s'avère suffisamment réactif pour pouvoir en général se passer
+ de manipuler les valeurs des directives
+ MinSpareServers,
+ MaxSpareServers et
+ StartServers. Lorsque plus de
+ 4 processus enfants sont lancés par seconde, un message est émis vers
+ le journal des erreurs. Si vous voyez apparaître souvent ce genre de
+ message, vous devez vous pencher sur ces réglages. Pour vous guider,
+ utilisez les informations délivrées par le module
+ mod_status.
À mettre en relation avec la création de processus, leur destruction
+ est définie par la valeur de la directive
+ MaxRequestsPerChild. Sa valeur
+ par défaut est 0, ce qui signifie qu'il n'y a pas de limite
+ au nombre de requêtes q'un processus enfant peut traiter. Si votre
+ configuration actuelle a cette directive réglée à une valeur très basse,
+ de l'ordre de 30, il est conseillé de l'augmenter de manière
+ significative. Si vous utilisez SunOs ou une ancienne version de Solaris,
+ utilisez une valeur de l'ordre de 10000 à cause des fuites
+ de mémoire.
Lorsqu'ils sont en mode "keep-alive", les processus enfants sont
+ maintenus et ne font rien sinon attendre la prochaine requête sur la
+ connexion déjà ouverte. La valeur par défaut de 5 de la
+ directive KeepAliveTimeout tend à
+ minimiser cet effet. Il faut trouver le bon compromis entre la bande
+ passante réseau et les ressources du serveur. En aucun cas vous ne devez
+ choisir une valeur supérieure à 60 seconds, car
+
+ la plupart des bénéfices sont alors perdus.
Apache 2.x supporte les modèles simultanés enfichables, appelés
+ Modules Multi-Processus (MPMs). Vous devez
+ choisir un MPM au moment de la construction d'Apache. Certaines
+ plateformes ont des modules MPM spécifiques :
+ mpm_netware, et
+ mpm_winnt. Sur les systèmes de type Unix, vous avez le
+ choix entre un grand nombre de modules MPM. Le choix du MPM peut affecter
+ la vitesse et l'évolutivité du démon httpd :
worker utilise plusieurs processus
+ enfants possédant chacun de nombreux threads. Chaque thread gère une
+ seule connexion à la fois. Worker est en général un bon choix pour les
+ serveurs présentant un traffic important car il possède une empreinte
+ mémoire plus petite que le MPM prefork.prefork utilise plusieurs processus enfants
+ possédant chacun un seul thread. Chaque processus gère une seule
+ connexion à la fois. Sur de nombreux systèmes, prefork est comparable
+ en matière de vitesse à worker, mais il utilise plus de mémoire. De par
+ sa conception sans thread, prefork présente des avantages par rapport à
+ worker dans certaines situations : il peut être utilisé avec les
+ modules tiers qui ne supportent pas le threading, et son débogage est plus
+ aisé sur les platesformes présentant un support du débogage des threads
+ rudimentaire.Pour plus d'informations sur ces deux MPMs et les autres, veuillez + vous référer à la documentation sur les + MPM.
+ + + +Comme le contrôle de l'utilisation de la mémoire est très important
+ en matière de performance, il est conseillé d'éliminer les modules que
+ vous n'utilisez pas vraiment. Si vous avez construit ces modules en
+ tant que DSOs, leur élimination consiste
+ simplement à commenter la directive
+ LoadModule associée à ce
+ module. Ceci vous permet de vérifier si votre site fonctionne toujours
+ après la suppression de tel ou tel module.
Par contre, si les modules que vous voulez supprimer sont liés + statiquement à votre binaire Apache, vous devrez recompiler ce dernier + afin de pouvoir les éliminer.
+ +La question qui découle de ce qui précède est évidemment de
+ savoir de quels modules vous avez besoin et desquels vous pouvez vous
+ passer. La réponse sera bien entendu différente d'un site web à
+ l'autre. Cependant, la liste minimale de modules nécessaire à
+ la survie de votre site contiendra certainement
+ mod_mime, mod_dir et
+ mod_log_config. mod_log_config est bien
+ entendu optionnel puisque vous pouvez faire fonctionner un site web
+ en se passant de fichiers journaux ; ceci est cependant
+ déconseillé.
Certains modules, à l'instar de mod_cache et des
+ versions de développement récentes du MPM worker, utilisent l'API
+ atomique d'APR. Cette API propose des opérations atomiques que l'on
+ peut utiliser pour alléger la synchronisation des threads.
Par défaut, APR implémente ces opérations en utilisant les
+ mécanismes les plus efficaces disponibles sur chaque plateforme cible
+ (Système d'exploitation et processeur). De nombreux processeurs modernes,
+ par exemple, possèdent une instruction qui effectue une opération
+ atomique de type comparaison et échange ou compare-and-swap (CAS) au
+ niveau matériel. Sur certaines platesformes cependant, APR utilise par
+ défaut une implémentation de l'API atomique plus lente, basée sur les
+ mutex, afin d'assurer la compatibilité avec les anciens modèles de
+ processeurs qui ne possèdent pas ce genre d'instruction. Si vous
+ construisez Apache pour une de ces platesformes, et ne prévoyez de
+ l'exécuter que sur des processeurs récents, vous pouvez sélectionner une
+ implémentation atomique plus rapide à la compilation en utilisant
+ l'option --enable-nonportable-atomics du
+ script configure :
+ ./buildconf
+ ./configure --with-mpm=worker --enable-nonportable-atomics=yes
+
L'option --enable-nonportable-atomics concerne les
+ platesformes suivantes :
--enable-nonportable-atomics au script configure, APR
+ génère un code qui utilise le code opération SPARC v8plus pour des
+ opérations de compare-and-swap matériel plus rapides. Si vous
+ utilisez cette option de configure avec Apache, les opérations
+ atomiques seront plus efficaces (permettant d'alléger la charge du
+ processeur et un plus haut niveau de simultanéité), mais
+ l'exécutable produit ne fonctionnera que sur les processeurs
+ UltraSPARC.
+ --enable-nonportable-atomics au script configure,
+ APR générera un code qui utilise un code d'opération du 486
+ pour des opérations de compare-and-swap matériel plus rapides. Le
+ code résultant est plus efficace en matière d'opérations atomiques,
+ mais l'exécutable produit ne fonctionnera que sur des processeurs
+ 486 et supérieurs (et non sur des 386).
+ Si vous incluez le module mod_status à la
+ construction d'Apache et ajoutez ExtendedStatus On à sa
+ configuration, Apache va effectuer pour chaque requête deux appels à
+ gettimeofday(2) (ou times(2) selon votre
+ système d'exploitation), et (pour les versions antérieures à 1.3) de
+ nombreux appels supplémentaires à time(2). Tous ces
+ appels sont effectués afin que le rapport de statut puisse contenir
+ des indications temporelles. Pour améliorer les performances, utilisez
+ ExtendedStatus off (qui est le réglage par défaut).
Cette section n'a pas été totalement mise à jour car elle ne tient pas + compte des changements intervenus dans la version 2.x du Serveur HTTP + Apache. Certaines informations sont encore pertinentes, il vous est + cependant conseillé de les utiliser avec prudence.
+Ce qui suit est une brève discussion à propos de l'API des sockets
+ Unix. Supposons que votre serveur web utilise plusieurs directives
+ Listen afin d'écouter
+ plusieurs ports ou de multiples adresses. Afin de tester chaque socket
+ pour voir s'il a une connexion en attente, Apache utilise
+ select(2). select(2) indique si un socket a
+ zéro ou au moins une connexion en attente. Le modèle
+ d'Apache comporte plusieurs processus enfants, et tous ceux qui sont
+ inactifs testent la présence de nouvelles connexions au même moment.
+ Une implémentation rudimentaire de ceci pourrait ressembler à
+ l'exemple suivant
+ (ces exemples ne sont pas extraits du code d'Apache, ils ne sont
+ proposés qu'à des fins pédagogiques) :
+ for (;;) {
+
+ for (;;) {
+
+ fd_set accept_fds;
+
+ FD_ZERO (&accept_fds);
+ for (i = first_socket; i <= last_socket; ++i) {
+
+ FD_SET (i, &accept_fds);
+
+ }
+ rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
+ if (rc < 1) continue;
+ new_connection = -1;
+ for (i = first_socket; i <= last_socket; ++i) {
+
+ if (FD_ISSET (i, &accept_fds)) {
+
+ new_connection = accept (i, NULL, NULL);
+ if (new_connection != -1) break;
+
+ }
+
+ }
+ if (new_connection != -1) break;
+
+ }
+ process the new_connection;
+
+ }
+
Mais cette implémentation rudimentaire présente une sérieuse lacune.
+ Rappelez-vous que les processus enfants exécutent cette boucle au même
+ moment ; ils vont ainsi bloquer sur select s'ils se trouvent
+ entre deux requêtes. Tous ces processus bloqués vont se réactiver et
+ sortir de select quand une requête va apparaître sur un des
+ sockets (le nombre de processus enfants qui se réactivent varie en
+ fonction du système d'exploitation et des réglages de synchronisation).
+ Ils vont alors tous entrer dans la boucle et tenter un
+ "accept" de la connexion. Mais seulement un d'entre eux y
+ parviendra (en supposant qu'il ne reste q'une seule connexion en
+ attente), les autres vont se bloquer au niveau de accept.
+ Ceci verrouille vraiment ces processus de telle sorte qu'ils ne peuvent
+ plus servir de requêtes que par cet unique socket, et il en sera ainsi
+ jusqu'à ce que suffisamment de nouvelles requêtes apparaissent sur ce
+ socket pour les réactiver tous. Cette lacune a été documentée pour la
+ première fois dans
+ PR#467. Il existe
+ au moins deux solutions.
La première consiste à rendre les sockets non blocants. Dans ce cas,
+ accept ne bloquera pas les processus enfants, et ils
+ pourront continuer à s'exécuter immédiatement. Mais ceci consomme des
+ ressources processeur. Supposons que vous ayez dix processus enfants
+ inactifs dans select, et qu'une connexion arrive.
+ Neuf des dix processus vont se réactiver, tenter un accept
+ de la connexion, échouer, et boucler dans select, tout en
+ n'ayant finalement rien accompli. Pendant ce temps, aucun de ces processus
+ ne traite les requêtes qui arrivent sur d'autres sockets jusqu'à ce
+ qu'ils retournent dans select. Finalement, cette solution
+ ne semble pas très efficace, à moins que vous ne disposiez d'autant de
+ processeurs inactifs (dans un serveur multiprocesseur) que de processus
+ enfants inactifs, ce qui n'est pas une situation très courante.
Une autre solution, celle qu'utilise Apache, consiste à sérialiser les + entrées dans la boucle interne. La boucle ressemble à ceci (les + différences sont mises en surbrillance) :
+ +
+ for (;;) {
+
+ accept_mutex_on ();
+ for (;;) {
+
+ fd_set accept_fds;
+
+ FD_ZERO (&accept_fds);
+ for (i = first_socket; i <= last_socket; ++i) {
+
+ FD_SET (i, &accept_fds);
+
+ }
+ rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
+ if (rc < 1) continue;
+ new_connection = -1;
+ for (i = first_socket; i <= last_socket; ++i) {
+
+ if (FD_ISSET (i, &accept_fds)) {
+
+ new_connection = accept (i, NULL, NULL);
+ if (new_connection != -1) break;
+
+ }
+
+ }
+ if (new_connection != -1) break;
+
+ }
+ accept_mutex_off ();
+ process the new_connection;
+
+ }
+
Les fonctions
+ accept_mutex_on et accept_mutex_off
+ implémentent un sémaphore permettant une exclusion mutuelle. Un seul
+ processus enfant à la fois peut posséder le mutex. Plusieurs choix se
+ présentent pour implémenter ces mutex. Ce choix est défini dans
+ src/conf.h (versions antérieures à 1.3) ou
+ src/include/ap_config.h (versions 1.3 ou supérieures).
+ Certaines architectures ne font pas ce choix du mode de verrouillage ;
+ l'utilisation de directives
+ Listen multiples sur ces
+ architectures est donc peu sûr.
On peut utiliser la directive
+ AcceptMutex pour modifier
+ l'implémentation du mutex sélectionnée à l'exécution.
AcceptMutex flockCette méthode utilise l'appel système flock(2) pour
+ créer un fichier verrou (dont la localisation est définie par la
+ directive LockFile.
AcceptMutex fcntlCette méthode utilise l'appel système fcntl(2) pour
+ créer un fichier verrou ((dont la localisation est définie par la
+ directive LockFile.
AcceptMutex sysvsem(Versions 1.3 ou supérieures) Cette méthode utilise les sémaphores
+ style SysV pour implémenter les mutex. Malheureusement, les
+ sémaphores style SysV ont quelques effets de bord néfastes. L'un
+ d'entre eux est la possibilité pour Apache de s'arrêter sans
+ "faire le ménage" dans les sémaphores (voir la page de manuel de
+ ipcs(8)). Un autre effet de bord est introduit par
+ l'API des sémaphores qui permet à tout CGI s'exécutant sous le même
+ uid que le serveur web d'effectuer une attaque par déni de service
+ (c'est à dire tous les CGIs, à moins que vous n'utilisiez
+ un programme comme suexec ou
+ cgiwrapper)..
AcceptMutex pthread(versions 1.3 ou supérieures) Cette méthode utilise les mutex + POSIX et devrait fonctionner sur toute architecture implémentant + de manière complète la spécification concernant les threads POSIX ; + il semble cependant qu'elle ne fonctionne que sur Solaris (versions + 2.5 ou supérieures), et sous certaines configurations seulement. Si + vous tentez l'expérience, votre serveur risque de se bloquer et de ne + plus répondre à vos sollicitations. Par contre, les serveurs + n'hébergeant que du contenu statique devraient fonctionner + correctement.
+AcceptMutex posixsem(Versions 2.0 ou supérieures) Cette méthode utilise les sémaphores + POSIX. L'appartenance du sémaphore n'est pas récupérée quand un + thread du processus qui détient le mutex provoque une erreur de + segmentation, ce qui a pour effet de bloquer le serveur.
+Si votre système propose une méthode de sérialisation différente de + celles de la liste ci-dessus, il pourrait être intéressant d'ajouter à + APR le code correspondant.
+ +Une autre solution qui a été imaginée mais jamais implémentée, consiste + à sérialiser partiellement la boucle -- c'est à dire y faire entrer un + certain nombre de processus. Ceci ne présenterait un intérêt que sur les + machines multiprocesseurs où plusieurs processus enfants peuvent + s'exécuter simultanément, et encore, la sérialisation ne tire pas + vraiment parti de toute la bande passante. C'est une possibilité + d'investigation future, mais demeure de priorité basse car les serveurs + web à architecture hautement parallèle ne sont pas la norme.
+ +Pour bien faire, vous devriez faire fonctionner votre serveur sans
+ directives Listen multiples
+ si vous visez les performances les plus élevées.
+ Mais lisez ce qui suit.
Ce qui précède convient pour les serveurs à sockets multiples, mais
+ qu'en est-il des serveurs à socket unique ? En théorie, ils ne
+ devraient pas rencontrer les mêmes problèmes car tous les processus
+ enfants peuvent se bloquer dans accept(2) jusqu'à ce qu'une
+ connexion arrive, et ils ne sont pas utilisés à ne rien faire. En
+ pratique, ceci dissimule un même comportement de bouclage
+ discuté plus haut dans la solution non-blocante. De la manière dont
+ sont implémentées les piles TCP, le noyau réactive véritablement tous les
+ processus bloqués dans accept quand une seule connexion
+ arrive. Un de ces processus prend la connexion en compte et retourne
+ dans l'espace utilisateur, les autres bouclant dans l'espace du
+ noyau et se désactivant quand ils s'aperçoivent qu'il n'y a pas de
+ connexion pour eux. Ce bouclage est invisible depuis le code de l'espace
+ utilisateur, mais il est quand-même présent. Ceci peut conduire à la
+ même augmentation de charge à perte que la solution non blocante au cas
+ des sockets multiples peut induire.
Pour cette raison, il apparaît que de nombreuses architectures se
+ comportent plus "proprement" si on sérialise même dans le cas d'une socket
+ unique. Il s'agit en fait du comportement par défaut dans la plupart des
+ cas. Des expériences poussées sous Linux (noyau 2.0.30 sur un
+ biprocesseur Pentium pro 166 avec 128 Mo de RAM) ont montré que la
+ sérialisation d'une socket unique provoque une diminution inférieure à 3%
+ du nombre de requêtes par secondes par rapport au traitement non
+ sérialisé. Mais le traitement non sérialisé des sockets uniques induit
+ un temps de réponse supplémentaire de 100 ms pour chaque requête. Ce
+ temps de réponse est probablement provoqué par une limitation sur les
+ lignes à haute charge, et ne constitue un problème que sur les réseaux
+ locaux. Si vous voulez vous passer de la sérialisation des sockets
+ uniques, vous pouvez définir
+ SINGLE_LISTEN_UNSERIALIZED_ACCEPT et les
+ serveurs à socket unique ne pratiqueront plus du tout la
+ sérialisation.
Comme discuté dans + draft-ietf-http-connection-00.txt section 8, pour implémenter de + manière fiable le protocole, un serveur HTTP doit fermer + les deux directions d'une communication indépendamment (rappelez-vous + qu'une connexion TCP est bidirectionnelle, chaque direction étant + indépendante de l'autre). Ce fait, souvent ignoré par les autres + serveurs, est implémenté correctement dans Apache depuis la + version 1.2.
+ +Quand cette fonctionnalité fut ajoutée à Apache, elle causa une
+ avalanche de problèmes sur plusieurs versions d'Unix à cause d'une
+ implémentation à courte vue. La spécification TCP ne précise pas que
+ l'état FIN_WAIT_2 possède un temps de réponse mais elle ne
+ l'exclut pas. Sur les systèmes qui n'introduisent pas ce temps de
+ réponse, Apache 1.2 induit de nombreux blocages définitifs de socket
+ dans l'état FIN_WAIT_2. On peut eviter ceci dans de nombreux
+ cas tout simplement en mettant à jour TCP/IP avec le dernier patch mis à
+ disposition par le fournisseur. Dans les cas où le fournisseur n'a
+ jamais fourni de patch (par exemple, SunOS4 -- bien que les utilisateurs
+ possédant une license source puissent le patcher eux-mêmes), nous avons
+ décidé de désactiver cette fonctionnalité.
Il y a deux méthodes pour arriver à ce résultat. La première est
+ l'option de socket SO_LINGER. Mais le sort a voulu que cette
+ solution ne soit jamais implémentée correctement dans la plupart des
+ piles TCP/IP. Et même dans les rares cas où cette solution a été
+ implémentée correctement (par exemple Linux 2.0.31), elle se
+ montre beaucoup plus gourmande (en temps processeur) que la solution
+ suivante.
Pour la plus grande partie, Apache implémente cette solution à l'aide
+ d'une fonction appelée lingering_close (définie dans
+ http_main.c). La fonction ressemble approximativement à
+ ceci :
+ void lingering_close (int s)
+ {
+
+ char junk_buffer[2048];
+
+ /* shutdown the sending side */
+ shutdown (s, 1);
+
+ signal (SIGALRM, lingering_death);
+ alarm (30);
+
+ for (;;) {
+
+ select (s for reading, 2 second timeout);
+ if (error) break;
+ if (s is ready for reading) {
+
+ if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {
+
+ break;
+
+ }
+ /* just toss away whatever is here */
+
+ }
+
+ }
+
+ close (s);
+
+ }
+
Ceci ajoute naturellement un peu de charge à la fin d'une connexion,
+ mais s'avère nécessaire pour une implémentation fiable. Comme HTTP/1.1
+ est de plus en plus présent et que toutes les connexions sont
+ persistentes, la charge sera amortie par la multiplicité des requêtes.
+ Si vous voulez jouer avec le feu en désactivant cette fonctionnalité,
+ vous pouvez définir NO_LINGCLOSE, mais c'est fortement
+ déconseillé. En particulier, comme les connexions persistantes en
+ pipeline de HTTP/1.1 commencent à être utilisées,
+ lingering_close devient une absolue nécessité (et les
+
+ connexions en pipeline sont plus rapides ; vous avez donc tout
+ intérêt à les supporter).
Les processus parent et enfants d'Apache communiquent entre eux à
+ l'aide d'un objet appelé "Tableau de bord" (Scoreboard). Idéalement, cet
+ échange devrait s'effectuer en mémoire partagée. Pour les systèmes
+ d'exploitation auxquels nous avons eu accès, ou pour lesquels nous avons
+ obtenu des informations suffisamment détaillées pour effectuer un
+ portage, cet échange est en général implémenté en utilisant la mémoire
+ partagée. Pour les autres, on utilise par défaut un fichier d'échange sur
+ disque. Le fichier d'échange sur disque est non seulement lent, mais
+ aussi peu fiable (et propose moins de fonctionnalités). Recherchez dans
+ le fichier src/main/conf.h correspondant à votre
+ architecture soit USE_MMAP_SCOREBOARD, soit
+ USE_SHMGET_SCOREBOARD. La définition de l'un des deux
+ (ainsi que leurs compagnons respectifs HAVE_MMAP et
+ HAVE_SHMGET), active le code fourni pour la mémoire
+ partagée. Si votre système propose une autre solution pour la gestion de
+ la mémoire partagée, éditez le fichier src/main/http_main.c
+ et ajoutez la portion de code nécessaire pour pouvoir l'utiliser dans
+ Apache (Merci de nous envoyer aussi le patch correspondant).
Si vous n'avez pas l'intention d'utiliser les modules chargés
+ dynamiquement (ce qui est probablement le cas si vous êtes en train de
+ lire ce document afin de personnaliser votre serveur en recherchant le
+ moindre des gains en performances), vous pouvez ajouter la définition
+ -DDYNAMIC_MODULE_LIMIT=0 à la construction de votre serveur.
+ Ceci aura pour effet de libérer la mémoire RAM allouée pour le
+ chargement dynamique des modules.
Voici la trace d'un appel système d'Apache 2.0.38 avec le MPM worker + sous Solaris 8. Cette trace a été collectée à l'aide de la commande :
+ +
+ truss -l -p httpd_child_pid.
+
L'option -l demande à truss de tracer l'ID du LWP
+ (lightweight process--la version de Solaris des threads niveau noyau) qui
+ invoque chaque appel système.
Les autres systèmes peuvent proposer des utilitaires de traçage
+ des appels système différents comme strace,
+ ktrace, ou par. Ils produisent cependant tous une
+ trace similaire.
Dans cette trace, un client a demandé un fichier statique de 10 ko au + démon httpd. Le traçage des requêtes pour des contenus non statiques + ou comportant une négociation de contenu a une présentation + différente (et même assez laide dans certains cas).
+ +/67: accept(3, 0x00200BEC, 0x00200C0C, 1) (sleeping...) +/67: accept(3, 0x00200BEC, 0x00200C0C, 1) = 9
Dans cette trace, le thread à l'écoute s'exécute à l'intérieur de + LWP #67.
+ +accept(2). Sur
+ cette plateforme spécifique, le MPM worker utilise un accept non sérialisé
+ par défaut sauf s'il est en écoute sur des ports multiples./65: lwp_park(0x00000000, 0) = 0 +/67: lwp_unpark(65, 1) = 0
Après avoir accepté la connexion, le thread à l'écoute réactive un + thread du worker pour effectuer le traitement de la requête. Dans cette + trace, le thread du worker qui traite la requête est associé à + LWP #65.
+ +/65: getsockname(9, 0x00200BA4, 0x00200BC4, 1) = 0
Afin de pouvoir implémenter les hôtes virtuels, Apache doit connaître
+ l'adresse du socket local utilisé pour accepter la connexion. On pourrait
+ supprimer cet appel dans de nombreuses situations (par exemple dans le cas
+ où il n'y a pas d'hôte virtuel ou dans le cas où les directives
+ Listen contiennent des adresses
+ sans caractères de substitution). Mais aucun effort n'a été accompli à ce
+ jour pour effectuer ces optimisations.
/65: brk(0x002170E8) = 0 +/65: brk(0x002190E8) = 0
L'appel brk(2) alloue de la mémoire dans le tas. Ceci est
+ rarement visible dans une trace d'appel système, car le démon httpd
+ utilise des allocateurs mémoire de son cru (apr_pool et
+ apr_bucket_alloc) pour la plupart des traitements de requêtes.
+ Dans cette trace, le démon httpd vient juste de démarrer, et il doit
+ appeler malloc(3) pour réserver les blocs de mémoire
+ nécessaires à la création de ses propres allocateurs de mémoire.
/65: fcntl(9, F_GETFL, 0x00000000) = 2 +/65: fstat64(9, 0xFAF7B818) = 0 +/65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B910, 2190656) = 0 +/65: fstat64(9, 0xFAF7B818) = 0 +/65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B914, 2190656) = 0 +/65: setsockopt(9, 65535, 8192, 0xFAF7B918, 4, 2190656) = 0 +/65: fcntl(9, F_SETFL, 0x00000082) = 0
Ensuite, le thread de worker passe la connexion du client (descripteur
+ de fichier 9) en mode non blocant. Les appels setsockopt(2)
+ et getsockopt(2) constituent un effet de bord de la manière
+ dont la libc de Solaris utilise fcntl(2) pour les sockets.
/65: read(9, " G E T / 1 0 k . h t m".., 8000) = 97
Le thread de worker lit la requête du client.
+ +/65: stat("/var/httpd/apache/httpd-8999/htdocs/10k.html", 0xFAF7B978) = 0
+/65: open("/var/httpd/apache/httpd-8999/htdocs/10k.html", O_RDONLY) = 10Ce démon httpd a été configuré avec les options
+ Options FollowSymLinks et AllowOverride None. Il
+ n'a donc ni besoin d'appeler lstat(2) pour chaque répertoire
+ du chemin du fichier demandé, ni besoin de vérifier la présence de fichiers
+ .htaccess. Il appelle simplement stat(2) pour
+ vérifier d'une part que le fichier existe, et d'autre part que c'est un
+ fichier régulier, et non un répertoire.
/65: sendfilev(0, 9, 0x00200F90, 2, 0xFAF7B53C) = 10269
Dans cet exemple, le démon httpd peut envoyer l'en-tête de la réponse
+ HTTP et le fichier demandé à l'aide d'un seul appel système
+ sendfilev(2). La sémantique de sendfile varie en fonction des
+ systèmes d'exploitation. Sur certains autres systèmes, il faut faire un
+ appel à write(2) ou writev(2) pour envoyer les
+ en-têtes avant d'appeler sendfile(2).
/65: write(4, " 1 2 7 . 0 . 0 . 1 - ".., 78) = 78
Cet appel à write(2) enregistre la requête dans le journal
+ des accès. Notez qu'une des choses manquant à cette trace est un appel à
+ time(2). A la différence d'Apache 1.3, Apache 2.x utilise
+ gettimeofday(3) pour consulter l'heure. Sur certains systèmes
+ d'exploitation, comme Linux ou Solaris, gettimeofday est
+ implémenté de manière optimisée de telle sorte qu'il consomme moins de
+ ressources qu'un appel système habituel.
/65: shutdown(9, 1, 1) = 0 +/65: poll(0xFAF7B980, 1, 2000) = 1 +/65: read(9, 0xFAF7BC20, 512) = 0 +/65: close(9) = 0
Le thread de worker effectue une fermeture "en prenant son temps" + (lingering close) de la connexion.
+ +/65: close(10) = 0 +/65: lwp_park(0x00000000, 0) (sleeping...)
Enfin, le thread de worker ferme le fichier qu'il vient de délivrer et + se bloque jusqu'à ce que le thread en écoute lui assigne une autre + connexion.
+ +/67: accept(3, 0x001FEB74, 0x001FEB94, 1) (sleeping...)
Pendant ce temps, le thread à l'écoute peut accepter une autre connexion
+ à partir du moment où il a assigné la connexion présente à un thread de
+ worker (selon une certaine logique de contrôle de flux dans le MPM worker
+ qui impose des limites au thread à l'écoute si tous les threads de worker
+ sont occupés). Bien que cela n'apparaisse pas dans cette trace,
+ l'accept(2) suivant peut (et le fait en général, en situation
+ de charge élevée) s'exécuter en parallèle avec le traitement de la
+ connexion qui vient d'être acceptée par le thread de worker.
Serveur Apache HTTP Version 2.3
-Ce document propose quelques conseils et astuces concernant les - problèmes de sécurité liés - à l'installation d'un serveur web. Certaines suggestions seront à caractère - général, tandis que d'autres seront spécifiques à Apache.
- Maintenez votre serveur à jour Attaques de type "Déni de service"
- (Denial of Service - DoS) Permissions sur les répertoires de la racine du serveur Inclusions côté serveur Les CGI en général CGI sans alias de script CGI avec alias de script Autres sources de contenu dynamique Protection de la configuration du système Protection par défaut des fichiers du serveur Surveillez vos journauxLe serveur HTTP Apache a une bonne réputation en matière de sécurité - et possède une communauté de développeurs très sensibilisés aux problèmes - de sécurité. Mais il est inévitable de trouver certains problèmes - -- petits ou grands -- une fois le logiciel mis à disposition. C'est pour - cette raison qu'il est crucial de se tenir informé des mises à jour. Si - vous avez obtenu votre version du serveur HTTP directement depuis Apache, - nous vous conseillons grandement de vous abonner à la Liste de diffusion - des annonces du serveur HTTP qui vous informera de - la parution des nouvelles versions et des mises à jour de sécurité. La - plupart des distributeurs tiers d'Apache fournissent des services - similaires.
- -Gardez cependant à l'esprit que lorsqu'un serveur web est compromis, le - code du serveur HTTP n'est la plupart du temps pas en cause. Les problèmes - proviennent plutôt de code ajouté, de scripts CGI, ou du système - d'exploitation sous-jacent. Vous devez donc vous tenir informé des - problèmes et mises à jour concernant tous les logiciels présents sur - votre système.
- -Tous les services réseau peuvent faire l'objet d'attaques de type - "Déni de service" qui tentent de les empêcher de répondre aux clients en - saturant leurs ressources. Il est impossible de se prémunir totalement - contre ce type d'attaques, mais vous pouvez accomplir certaines actions - afin de minimiser les problèmes qu'elles créent.
- -Souvent, l'outil anti-DoS le plus efficace sera constitué par le - pare-feu ou certaines configurations du système d'exploitation. Par - exemple, la plupart des pare-feu peuvent être configurés de façon à - limiter le nombre de connexions simultanées depuis une adresse IP ou un - réseau, ce qui permet de prévenir toute une gamme d'attaques simples. - Bien sûr, ceci n'est d'aucun secours contre les attaques de type - "Déni de service" distribuées (DDoS).
- -Certains réglages de la configuration d'Apache peuvent aussi - minimiser les problèmes :
- -TimeOut doit être diminuée sur les
- sites sujets aux attaques DoS. Une valeur de quelques secondes devrait
- convenir. Cependant, comme TimeOut
- est actuellement concerné par de nombreuses opérations différentes, lui
- attribuer une valeur trop faible peut provoquer des problèmes avec les
- scripts CGI qui présentent un long temps de réponse.KeepAliveTimeout doit aussi être
- diminuée sur les sites sujets aux attaques DoS. Certains sites
- désactivent même complètement le "maintien en vie" (keepalives)
- à l'aide de la directive
- KeepAlive, ce qui bien sûr
- présente des inconvénients en matière de performances.LimitRequestBody,
- LimitRequestFields,
- LimitRequestFieldSize,
- LimitRequestLine, et
- LimitXMLRequestBody doivent être
- configurées avec prudence afin de limiter la consommation de ressources
- induite par les demandes des clients.
- AcceptFilter est
- activée afin de déléguer une partie du traitement des requêtes au
- système d'exploitation. Elle est activée par défaut dans le démon httpd
- d'Apache, mais peut nécessiter une reconfiguration de votre noyau.MaxClients de façon à définir le nombre
- maximum de connexions simultanées au dessus duquel les ressources
- s'épuisent. Voir aussi la documentation sur l'optimisation des
- performances.event utilisera un traitement asynchrone afin de ne pas
- dédier un thread à chaque connexion. Il est en cours d'étude à
- l'heure actuelle et n'est pas encore entièrement implémenté. En
- particulier, le mpm event est actuellement incompatible
- avec le module mod_ssl ainsi que d'autres filtres
- en entrée.Typiquement, Apache est démarré par l'utilisateur root, puis il devient
- la propriété de l'utilisateur défini par la directive User afin de répondre aux demandes. Comme
- pour toutes les commandes exécutées par root, vous devez vous assurer
- qu'elle n'est pas modifiable par les utilisateurs autres que root. Les
- fichiers eux-mêmes, mais aussi les répertoires ainsi que leurs parents ne
- doivent être modifiables que par root. Par exemple, si vous avez choisi de
- placer la racine du serveur dans /usr/local/apache, il est conseillé de
- créer le répertoire en tant que root, avec des commandes du style :
- mkdir /usr/local/apache
- cd /usr/local/apache
- mkdir bin conf logs
- chown 0 . bin conf logs
- chgrp 0 . bin conf logs
- chmod 755 . bin conf logs
-
Nous supposerons que /, /usr et
- /usr/local ne sont modifiables que par
- root. Quand vous installez l'exécutable httpd, vous
- devez vous assurer qu'il possède des protections similaires :
- cp httpd /usr/local/apache/bin
- chown 0 /usr/local/apache/bin/httpd
- chgrp 0 /usr/local/apache/bin/httpd
- chmod 511 /usr/local/apache/bin/httpd
-
Vous pouvez créer un sous-répertoire htdocs modifiable par d'autres - utilisateurs -- car root ne crée ni exécute aucun fichier dans ce - sous-répertoire.
- -Si vous permettez à des utilisateurs non root de modifier des fichiers
- que root écrit ou exécute, vous exposez votre système à une compromission
- de l'utilisateur root. Par exemple, quelqu'un pourrait remplacer le binaire
- httpd de façon à ce que la prochaine fois que vous le
- redémarrerez, il exécutera un code arbitraire. Si le répertoire des
- journaux a les droits en écriture (pour un utilisateur non root), quelqu'un
- pourrait remplacer un fichier journal par un lien symbolique vers un autre
- fichier système, et root pourrait alors écraser ce fichier avec des données
- arbitraires. Si les fichiers journaux eux-mêmes ont des droits en
- écriture (pour un utilisateur non root), quelqu'un pourrait
- modifier les journaux eux-mêmes avec des données fausses.
Les inclusions côté serveur (Server Side Includes - SSI) exposent - l'administrateur du serveur à de nombreux risques potentiels en matière de - sécurité.
- -Le premier risque est l'augmentation de la charge du serveur. Tous les - fichiers où SSI est activé doivent être analysés par Apache, qu'ils - contiennent des directives SSI ou non. L'augmentation de la charge induite - est minime, mais peut devenir significative dans le contexte d'un - serveur partagé.
- -Les fichiers SSI présentent les mêmes risques que les scripts CGI en
- général. Les fichiers où SSI est activé peuvent exécuter tout script CGI
- ou autre programme à l'aide de la commande "exec cmd" avec les permissions
- des utilisateur et groupe sous lesquels Apache s'exécute, comme défini
- dans httpd.conf.
Des méthodes existent pour améliorer la sécurité des fichiers SSI, tout - en tirant parti des bénéfices qu'ils apportent.
- -Pour limiter les dommages qu'un fichier SSI agressif pourrait causer, - l'administrateur du serveur peut activersuexec - comme décrit dans la section Les CGI en général.
- -L'activation des SSI pour des fichiers possédant des extensions
- .html ou
- .htm peut s'avérer dangereux. Ceci est particulièrement vrai dans un
- environnement de serveur partagé ou étant le siège d'un traffic élevé. Les
- fichiers où SSI est activé doivent posséder une extension spécifique, telle
- que la conventionnelle .shtml. Ceci permet de limiter la charge du serveur
- à un niveau minimum et de simplifier la gestion des risques.
Une autre solution consiste à interdire l'exécution de scripts et
- programmes à partir de pages SSI. Pour ce faire, remplacez
- Includes par IncludesNOEXEC dans la directive
- Options. Notez que les utilisateurs
- pourront encore utiliser <--#include virtual="..." --> pour exécuter
- des scripts CGI si ces scripts sont situés dans des répertoires spécifiés
- par une directive
- ScriptAlias.
Tout d'abord, vous devez toujours garder à l'esprit que vous devez - faire confiance aux développeurs de scripts ou programmes CGI ainsi qu'à - vos compétences pour déceler les trous de sécurité potentiels dans les - CGI, que ceux-ci soient délibérés ou accidentels. Les scripts CGI peuvent - essentiellement exécuter des commandes arbitraires sur votre système avec - les droits de l'utilisateur du serveur web, et peuvent par conséquent être - extrèmement dangereux s'ils ne sont pas vérifiés avec soin.
- -Tous les scripts CGI s'exécutent sous le même utilisateur, il peuvent - donc entrer en conflit (accidentellement ou délibérément) avec d'autres - scripts. Par exemple, l'utilisateur A hait l'utilisateur B, il écrit donc - un script qui efface la base de données CGI de l'utilisateur B. Vous pouvez - utiliser le programme suEXEC pour faire en - sorte que les scripts s'exécutent sous des utilisateurs différents. Ce - programme est inclus dans la distribution d'Apache depuis la version 1.2 - et est appelé à partir de certaines portions de code du serveur Apache. Une - autre méthode plus connue est l'utilisation de - CGIWrap.
- -Vous ne devez permettre aux utilisateurs d'exécuter des scripts CGI - depuis n'importe quel répertoire que dans l'éventualité où :
- -Le confinement des CGI dans des répertoires spécifiques permet à - l'administrateur de contrôler ce que l'on met dans ces répertoires. Ceci - est bien entendu mieux sécurisé que les CGI sans alias de script, mais - seulement à condition que les utilisateurs avec les droits en écriture sur - les répertoires soient dignes de confiance, et que l'administrateur ait la - volonté de tester chaque programme ou script CGI à la recherche d'éventuels - trous de sécurité.
- -La plupart des sites choisissent cette approche au détriment des CGI - sans alias de script.
- -
- Les options de scripting intégrées qui s'exécutent en tant que partie du
- serveur lui-même, comme mod_php, mod_perl,
- mod_tcl, et mod_python,
- s'exécutent sous le même utilisateur que le serveur (voir la directive
- User), et par conséquent,
- les scripts que ces moteurs exécutent peuvent accéder aux mêmes ressources
- que le serveur. Certains moteurs de scripting peuvent proposer des
- restrictions, mais pour plus de sûreté, il vaut mieux partir du principe
- que ce n'est pas le cas.
Pour contrôler étroitement votre serveur, vous pouvez interdire
- l'utilisation des fichiers .htaccess qui permettent de
- passer outre les fonctionnalités de sécurité que vous avez configurées.
- Voici un moyen pour y parvenir :
Ajoutez dans le fichier de configuration du serveur
- -
- <Directory />
- AllowOverride None
- </Directory>
-
Ceci interdit l'utilisation des fichiers .htaccess dans
- tous les répertoires, sauf ceux pour lesquels c'est explicitement
- autorisé.
Le concept d'accès par défaut est un aspect d'Apache qui est parfois mal - compris. C'est à dire que, à moins que vous ne changiez explicitement ce - comportement, si le serveur trouve son chemin vers un fichier en suivant - les règles normales de correspondance URL - fichier, il peut le retourner - aux clients.
- -Considérons l'exemple suivant :
- -
- # cd /; ln -s / public_html
- puis accès à http://localhost/~root/
-
Ceci permettrait aux clients de parcourir l'ensemble du système de - fichiers. Pour l'éviter, ajoutez le bloc suivant à la configuration - de votre serveur :
- -
- <Directory />
- Order Deny,Allow
- Deny from all
- </Directory>
-
ceci va interdire l'accès par défaut à tous les fichiers du système de
- fichiers. Vous devrez ensuite ajouter les blocs
- Directory appropriés correspondant
- aux répertoires auxquels vous voulez autorisez l'accès. Par exemple,
- <Directory /usr/users/*/public_html>
- Order Deny,Allow
- Allow from all
- </Directory>
- <Directory /usr/local/httpd>
- Order Deny,Allow
- Allow from all
- </Directory>
-
Portez une attention particulière aux interactions entre les directives
- Location et
- Directory ; par exemple, si une
- directive <Directory /> interdit un accès, une
- directive <Location /> pourra passer outre.
De même, soyez méfiant en jouant avec la directive
- UserDir ; la positionner à
- "./" aurait le même effet, pour root, que le premier exemple plus haut.
- Si vous utilisez Apache version 1.3 ou supérieure, nous vous conseillons
- fortement d'inclure la ligne suivante dans le fichier de configuration de
- votre serveur :
- UserDir disabled root
-
Pour vous tenir informé de ce qui se passe réellement dans votre - serveur, vous devez consulter vos - fichiers journaux. Même si les fichiers journaux - ne consignent que des évènements qui se sont déjà produits, ils vous - informeront sur la nature des attaques qui sont lancées contre le serveur - et vous permettront de vérifier si le niveau de sécurité nécessaire est - atteint.
- -Quelques exemples :
- -
- grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log
- grep "client denied" error_log | tail -n 10
-
Le premier exemple listera les attaques essayant d'exploiter la - vulnérabilité - d'Apache Tomcat pouvant provoquer la divulgation d'informations par des - requêtes Source.JSP mal formées, le second donnera la liste des dix - dernières interdictions client ; par exemple :
- -
- [Thu Jul 11 17:18:39 2002] [error] [client foo.example.com] client denied
- by server configuration: /usr/local/apache/htdocs/.htpasswd
-
Comme vous le voyez, les fichiers journaux ne consignent que ce qui
- s'est déjà produit ; ainsi, si le client a pu accéder au fichier
- .htpasswd, vous devriez avoir quelque chose du style :
- foo.example.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"
-
dans votre journal des accès ; ce - qui signifie que vous avez probablement mis en commentaire ce qui suit dans - le fichier de configuration de votre serveur :
- -
- <Files ~ "^\.ht">
- Order allow,deny
- Deny from all
- </Files>
-
Serveur Apache HTTP Version 2.3
+Ce document propose quelques conseils et astuces concernant les + problèmes de sécurité liés + à l'installation d'un serveur web. Certaines suggestions seront à caractère + général, tandis que d'autres seront spécifiques à Apache.
+ Maintenez votre serveur à jour Attaques de type "Déni de service"
+ (Denial of Service - DoS) Permissions sur les répertoires de la racine du serveur Inclusions côté serveur Les CGI en général CGI sans alias de script CGI avec alias de script Autres sources de contenu dynamique Protection de la configuration du système Protection par défaut des fichiers du serveur Surveillez vos journauxLe serveur HTTP Apache a une bonne réputation en matière de sécurité + et possède une communauté de développeurs très sensibilisés aux problèmes + de sécurité. Mais il est inévitable de trouver certains problèmes + -- petits ou grands -- une fois le logiciel mis à disposition. C'est pour + cette raison qu'il est crucial de se tenir informé des mises à jour. Si + vous avez obtenu votre version du serveur HTTP directement depuis Apache, + nous vous conseillons grandement de vous abonner à la Liste de diffusion + des annonces du serveur HTTP qui vous informera de + la parution des nouvelles versions et des mises à jour de sécurité. La + plupart des distributeurs tiers d'Apache fournissent des services + similaires.
+ +Gardez cependant à l'esprit que lorsqu'un serveur web est compromis, le + code du serveur HTTP n'est la plupart du temps pas en cause. Les problèmes + proviennent plutôt de code ajouté, de scripts CGI, ou du système + d'exploitation sous-jacent. Vous devez donc vous tenir informé des + problèmes et mises à jour concernant tous les logiciels présents sur + votre système.
+ +Tous les services réseau peuvent faire l'objet d'attaques de type + "Déni de service" qui tentent de les empêcher de répondre aux clients en + saturant leurs ressources. Il est impossible de se prémunir totalement + contre ce type d'attaques, mais vous pouvez accomplir certaines actions + afin de minimiser les problèmes qu'elles créent.
+ +Souvent, l'outil anti-DoS le plus efficace sera constitué par le + pare-feu ou certaines configurations du système d'exploitation. Par + exemple, la plupart des pare-feu peuvent être configurés de façon à + limiter le nombre de connexions simultanées depuis une adresse IP ou un + réseau, ce qui permet de prévenir toute une gamme d'attaques simples. + Bien sûr, ceci n'est d'aucun secours contre les attaques de type + "Déni de service" distribuées (DDoS).
+ +Certains réglages de la configuration d'Apache peuvent aussi + minimiser les problèmes :
+ +TimeOut doit être diminuée sur les
+ sites sujets aux attaques DoS. Une valeur de quelques secondes devrait
+ convenir. Cependant, comme TimeOut
+ est actuellement concerné par de nombreuses opérations différentes, lui
+ attribuer une valeur trop faible peut provoquer des problèmes avec les
+ scripts CGI qui présentent un long temps de réponse.KeepAliveTimeout doit aussi être
+ diminuée sur les sites sujets aux attaques DoS. Certains sites
+ désactivent même complètement le "maintien en vie" (keepalives)
+ à l'aide de la directive
+ KeepAlive, ce qui bien sûr
+ présente des inconvénients en matière de performances.LimitRequestBody,
+ LimitRequestFields,
+ LimitRequestFieldSize,
+ LimitRequestLine, et
+ LimitXMLRequestBody doivent être
+ configurées avec prudence afin de limiter la consommation de ressources
+ induite par les demandes des clients.
+ AcceptFilter est
+ activée afin de déléguer une partie du traitement des requêtes au
+ système d'exploitation. Elle est activée par défaut dans le démon httpd
+ d'Apache, mais peut nécessiter une reconfiguration de votre noyau.MaxClients de façon à définir le nombre
+ maximum de connexions simultanées au dessus duquel les ressources
+ s'épuisent. Voir aussi la documentation sur l'optimisation des
+ performances.event utilisera un traitement asynchrone afin de ne pas
+ dédier un thread à chaque connexion. Il est en cours d'étude à
+ l'heure actuelle et n'est pas encore entièrement implémenté. En
+ particulier, le mpm event est actuellement incompatible
+ avec le module mod_ssl ainsi que d'autres filtres
+ en entrée.Typiquement, Apache est démarré par l'utilisateur root, puis il devient
+ la propriété de l'utilisateur défini par la directive User afin de répondre aux demandes. Comme
+ pour toutes les commandes exécutées par root, vous devez vous assurer
+ qu'elle n'est pas modifiable par les utilisateurs autres que root. Les
+ fichiers eux-mêmes, mais aussi les répertoires ainsi que leurs parents ne
+ doivent être modifiables que par root. Par exemple, si vous avez choisi de
+ placer la racine du serveur dans /usr/local/apache, il est conseillé de
+ créer le répertoire en tant que root, avec des commandes du style :
+ mkdir /usr/local/apache
+ cd /usr/local/apache
+ mkdir bin conf logs
+ chown 0 . bin conf logs
+ chgrp 0 . bin conf logs
+ chmod 755 . bin conf logs
+
Nous supposerons que /, /usr et
+ /usr/local ne sont modifiables que par
+ root. Quand vous installez l'exécutable httpd, vous
+ devez vous assurer qu'il possède des protections similaires :
+ cp httpd /usr/local/apache/bin
+ chown 0 /usr/local/apache/bin/httpd
+ chgrp 0 /usr/local/apache/bin/httpd
+ chmod 511 /usr/local/apache/bin/httpd
+
Vous pouvez créer un sous-répertoire htdocs modifiable par d'autres + utilisateurs -- car root ne crée ni exécute aucun fichier dans ce + sous-répertoire.
+ +Si vous permettez à des utilisateurs non root de modifier des fichiers
+ que root écrit ou exécute, vous exposez votre système à une compromission
+ de l'utilisateur root. Par exemple, quelqu'un pourrait remplacer le binaire
+ httpd de façon à ce que la prochaine fois que vous le
+ redémarrerez, il exécutera un code arbitraire. Si le répertoire des
+ journaux a les droits en écriture (pour un utilisateur non root), quelqu'un
+ pourrait remplacer un fichier journal par un lien symbolique vers un autre
+ fichier système, et root pourrait alors écraser ce fichier avec des données
+ arbitraires. Si les fichiers journaux eux-mêmes ont des droits en
+ écriture (pour un utilisateur non root), quelqu'un pourrait
+ modifier les journaux eux-mêmes avec des données fausses.
Les inclusions côté serveur (Server Side Includes - SSI) exposent + l'administrateur du serveur à de nombreux risques potentiels en matière de + sécurité.
+ +Le premier risque est l'augmentation de la charge du serveur. Tous les + fichiers où SSI est activé doivent être analysés par Apache, qu'ils + contiennent des directives SSI ou non. L'augmentation de la charge induite + est minime, mais peut devenir significative dans le contexte d'un + serveur partagé.
+ +Les fichiers SSI présentent les mêmes risques que les scripts CGI en
+ général. Les fichiers où SSI est activé peuvent exécuter tout script CGI
+ ou autre programme à l'aide de la commande "exec cmd" avec les permissions
+ des utilisateur et groupe sous lesquels Apache s'exécute, comme défini
+ dans httpd.conf.
Des méthodes existent pour améliorer la sécurité des fichiers SSI, tout + en tirant parti des bénéfices qu'ils apportent.
+ +Pour limiter les dommages qu'un fichier SSI agressif pourrait causer, + l'administrateur du serveur peut activersuexec + comme décrit dans la section Les CGI en général.
+ +L'activation des SSI pour des fichiers possédant des extensions
+ .html ou
+ .htm peut s'avérer dangereux. Ceci est particulièrement vrai dans un
+ environnement de serveur partagé ou étant le siège d'un traffic élevé. Les
+ fichiers où SSI est activé doivent posséder une extension spécifique, telle
+ que la conventionnelle .shtml. Ceci permet de limiter la charge du serveur
+ à un niveau minimum et de simplifier la gestion des risques.
Une autre solution consiste à interdire l'exécution de scripts et
+ programmes à partir de pages SSI. Pour ce faire, remplacez
+ Includes par IncludesNOEXEC dans la directive
+ Options. Notez que les utilisateurs
+ pourront encore utiliser <--#include virtual="..." --> pour exécuter
+ des scripts CGI si ces scripts sont situés dans des répertoires spécifiés
+ par une directive
+ ScriptAlias.
Tout d'abord, vous devez toujours garder à l'esprit que vous devez + faire confiance aux développeurs de scripts ou programmes CGI ainsi qu'à + vos compétences pour déceler les trous de sécurité potentiels dans les + CGI, que ceux-ci soient délibérés ou accidentels. Les scripts CGI peuvent + essentiellement exécuter des commandes arbitraires sur votre système avec + les droits de l'utilisateur du serveur web, et peuvent par conséquent être + extrèmement dangereux s'ils ne sont pas vérifiés avec soin.
+ +Tous les scripts CGI s'exécutent sous le même utilisateur, il peuvent + donc entrer en conflit (accidentellement ou délibérément) avec d'autres + scripts. Par exemple, l'utilisateur A hait l'utilisateur B, il écrit donc + un script qui efface la base de données CGI de l'utilisateur B. Vous pouvez + utiliser le programme suEXEC pour faire en + sorte que les scripts s'exécutent sous des utilisateurs différents. Ce + programme est inclus dans la distribution d'Apache depuis la version 1.2 + et est appelé à partir de certaines portions de code du serveur Apache. Une + autre méthode plus connue est l'utilisation de + CGIWrap.
+ +Vous ne devez permettre aux utilisateurs d'exécuter des scripts CGI + depuis n'importe quel répertoire que dans l'éventualité où :
+ +Le confinement des CGI dans des répertoires spécifiques permet à + l'administrateur de contrôler ce que l'on met dans ces répertoires. Ceci + est bien entendu mieux sécurisé que les CGI sans alias de script, mais + seulement à condition que les utilisateurs avec les droits en écriture sur + les répertoires soient dignes de confiance, et que l'administrateur ait la + volonté de tester chaque programme ou script CGI à la recherche d'éventuels + trous de sécurité.
+ +La plupart des sites choisissent cette approche au détriment des CGI + sans alias de script.
+ +
+ Les options de scripting intégrées qui s'exécutent en tant que partie du
+ serveur lui-même, comme mod_php, mod_perl,
+ mod_tcl, et mod_python,
+ s'exécutent sous le même utilisateur que le serveur (voir la directive
+ User), et par conséquent,
+ les scripts que ces moteurs exécutent peuvent accéder aux mêmes ressources
+ que le serveur. Certains moteurs de scripting peuvent proposer des
+ restrictions, mais pour plus de sûreté, il vaut mieux partir du principe
+ que ce n'est pas le cas.
Pour contrôler étroitement votre serveur, vous pouvez interdire
+ l'utilisation des fichiers .htaccess qui permettent de
+ passer outre les fonctionnalités de sécurité que vous avez configurées.
+ Voici un moyen pour y parvenir :
Ajoutez dans le fichier de configuration du serveur
+ +
+ <Directory />
+ AllowOverride None
+ </Directory>
+
Ceci interdit l'utilisation des fichiers .htaccess dans
+ tous les répertoires, sauf ceux pour lesquels c'est explicitement
+ autorisé.
Le concept d'accès par défaut est un aspect d'Apache qui est parfois mal + compris. C'est à dire que, à moins que vous ne changiez explicitement ce + comportement, si le serveur trouve son chemin vers un fichier en suivant + les règles normales de correspondance URL - fichier, il peut le retourner + aux clients.
+ +Considérons l'exemple suivant :
+ +
+ # cd /; ln -s / public_html
+ puis accès à http://localhost/~root/
+
Ceci permettrait aux clients de parcourir l'ensemble du système de + fichiers. Pour l'éviter, ajoutez le bloc suivant à la configuration + de votre serveur :
+ +
+ <Directory />
+ Order Deny,Allow
+ Deny from all
+ </Directory>
+
ceci va interdire l'accès par défaut à tous les fichiers du système de
+ fichiers. Vous devrez ensuite ajouter les blocs
+ Directory appropriés correspondant
+ aux répertoires auxquels vous voulez autorisez l'accès. Par exemple,
+ <Directory /usr/users/*/public_html>
+ Order Deny,Allow
+ Allow from all
+ </Directory>
+ <Directory /usr/local/httpd>
+ Order Deny,Allow
+ Allow from all
+ </Directory>
+
Portez une attention particulière aux interactions entre les directives
+ Location et
+ Directory ; par exemple, si une
+ directive <Directory /> interdit un accès, une
+ directive <Location /> pourra passer outre.
De même, soyez méfiant en jouant avec la directive
+ UserDir ; la positionner à
+ "./" aurait le même effet, pour root, que le premier exemple plus haut.
+ Si vous utilisez Apache version 1.3 ou supérieure, nous vous conseillons
+ fortement d'inclure la ligne suivante dans le fichier de configuration de
+ votre serveur :
+ UserDir disabled root
+
Pour vous tenir informé de ce qui se passe réellement dans votre + serveur, vous devez consulter vos + fichiers journaux. Même si les fichiers journaux + ne consignent que des évènements qui se sont déjà produits, ils vous + informeront sur la nature des attaques qui sont lancées contre le serveur + et vous permettront de vérifier si le niveau de sécurité nécessaire est + atteint.
+ +Quelques exemples :
+ +
+ grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log
+ grep "client denied" error_log | tail -n 10
+
Le premier exemple listera les attaques essayant d'exploiter la + vulnérabilité + d'Apache Tomcat pouvant provoquer la divulgation d'informations par des + requêtes Source.JSP mal formées, le second donnera la liste des dix + dernières interdictions client ; par exemple :
+ +
+ [Thu Jul 11 17:18:39 2002] [error] [client foo.example.com] client denied
+ by server configuration: /usr/local/apache/htdocs/.htpasswd
+
Comme vous le voyez, les fichiers journaux ne consignent que ce qui
+ s'est déjà produit ; ainsi, si le client a pu accéder au fichier
+ .htpasswd, vous devriez avoir quelque chose du style :
+ foo.example.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"
+
dans votre journal des accès ; ce + qui signifie que vous avez probablement mis en commentaire ce qui suit dans + le fichier de configuration de votre serveur :
+ +
+ <Files ~ "^\.ht">
+ Order allow,deny
+ Deny from all
+ </Files>
+
A single NameVirtualHost directive
identifies a set of identical virtual hosts on which the server will
further select from on the basis of the hostname
-requested by the client. The NameVirtualHost
+requested by the client. The NameVirtualHost
directive is a required directive if you want to configure
name-based virtual hosts.
| Açıklama: | Apache HTTP Sunucusunda daima mevcut olan çekirdek özellikler |
|---|---|
| Durum: | Çekirdek |
A single NameVirtualHost
+requested by the client. The
Apache HTTP Server Version 2.3
-Available Languages: en
-| Description: | Slot-based shared memory provider. |
|---|---|
| Status: | Extension |
| Module Identifier: | plainmem_module |
| Source File: | mod_plainmem.c |
mod_plainmem is a memory provider which
- provides for creation and access to a plain memory segment
- in which the datasets are organized in "slots." Although
- it can be used directly, normally mod_slotmem
- is used as a front-end.
-
If the memory needs to be shared between threads and
- processes, a better provider would be
- mod_sharedmem.
-
mod_plainmem provides the following
- API functions:
-
This module provides no - directives.
-Available Languages: en
-Apache HTTP Server Version 2.3
+Available Languages: en
+| Description: | Slot-based shared memory provider. |
|---|---|
| Status: | Extension |
| Module Identifier: | plainmem_module |
| Source File: | mod_plainmem.c |
mod_plainmem is a memory provider which
+ provides for creation and access to a plain memory segment
+ in which the datasets are organized in "slots." Although
+ it can be used directly, normally mod_slotmem
+ is used as a front-end.
+
If the memory needs to be shared between threads and
+ processes, a better provider would be
+ mod_sharedmem.
+
mod_plainmem provides the following
+ API functions:
+
This module provides no + directives.
+Available Languages: en
+Apache HTTP Server Version 2.3
-Available Languages: en
-| Description: | fdpass external process support module for
-mod_proxy |
|---|---|
| Status: | Extension |
| Module Identifier: | proxy_fdpass_module |
| Source File: | mod_proxy_fdpass.c |
| Compatibility: | Available for unix in version 2.3 and later |
This module requires the service of mod_proxy. It provides support for the passing the socket of the
- client to another process.
mod_proxy_fdpass uses the ability of AF_UNIX domain
- sockets to pass an
- open file descriptor to allow another process to finish handling a request.
-
The module has a proxy_fdpass_flusher provider interface,
- which allows another module to optionally send the response headers, or even
- the start of the response body. The default flush provider disables keep-alive,
- and sends the response headers, letting the external process just send a
- response body.
At this time the only data passed to the external process is the client
- socket. To recieve a client socket, call recvfrom with the an allocated
- struct cmsghdr. Future versions of this module may include
- more data after the client socket, but this is not implemented at this time.
-
Available Languages: en
-Apache HTTP Server Version 2.3
+Available Languages: en
+| Description: | fdpass external process support module for
+mod_proxy |
|---|---|
| Status: | Extension |
| Module Identifier: | proxy_fdpass_module |
| Source File: | mod_proxy_fdpass.c |
| Compatibility: | Available for unix in version 2.3 and later |
This module requires the service of mod_proxy. It provides support for the passing the socket of the
+ client to another process.
mod_proxy_fdpass uses the ability of AF_UNIX domain
+ sockets to pass an
+ open file descriptor to allow another process to finish handling a request.
+
The module has a proxy_fdpass_flusher provider interface,
+ which allows another module to optionally send the response headers, or even
+ the start of the response body. The default flush provider disables keep-alive,
+ and sends the response headers, letting the external process just send a
+ response body.
At this time the only data passed to the external process is the client
+ socket. To recieve a client socket, call recvfrom with the an allocated
+ struct cmsghdr. Future versions of this module may include
+ more data after the client socket, but this is not implemented at this time.
+
Available Languages: en
+Apache HTTP Server Version 2.3
+Available Languages: en
+| Description: | Replaces the apparent client remote IP address and hostname +for the request with the IP address list presented by a proxies or a load +balancer via the request headers. + |
|---|---|
| Status: | Base |
| Module Identifier: | remoteip_module |
| Source File: | mod_remoteip.c |
This module is used to treat the remote host which initiated the + request as the originating remote host as identified by httpd for the + purposes of authorization and logging, even where that remote host is + behind a load balancer, front end server, or proxy server.
+ +The module replaces the apparent remote (client) IP/hostname for
+ the request with the IP address reported in the request header
+ configured with the RemoteIPHeader directive.
Once replaced as instructed, this apparent IP address is then used
+ for mod_authz_host features
+ <Require host>
+ and <Require ip>,
+ is reported by mod_status, and is recorded by
+ mod_log_config %a and %h
+ directives. It also determines the machine probed for an inetd
+ identity by mod_ident based on the
+ IdentityCheck configuration.
RemoteIPHeader RemoteIPInternalProxy RemoteIPInternalProxyList RemoteIPProxiesHeader RemoteIPTrustedProxy RemoteIPTrustedProxyListApache identifies the client with the connection's remote_ip value, + and the connection remote_host and remote_logname are derived from this + value. These fields play a role in authentication, authorization and + logging and other purposes by other loadable modules.
+ +mod_remoteip replaces the true remote_ip with the advertised remote_ip as + provided by a proxy, for every evaluation of the client that occurs in the + server, and resets the remote_host and remote_logname values to trigger a + fresh dns or ident query of the remote IP address.
+ +When multiple, comma delimited remote IP addresses are listed in the + header value, they are processed in Right-to-Left order. Processessing + halts when the a given remote IP address is not trusted to present the + preceeding IP address. The header field is updated to this remaining + list of unconfirmed IP addresses, or if all IP addresses were trusted, + this header is removed from the request altogether.
+ +In replacing the remote_ip, the module stores the list of intermediate
+ hosts in a remoteip-proxy-ip-list note, which mod_log_config
+ can record using the %{remoteip-proxy-ip-list}n format token.
+ If the administrator needs to store this as an additional header, this
+ same value can also be recording as a header using the directive
+ RemoteIPProxiesHeader.
RemoteIPInternalProxy
+ internal (intranet) proxies are registered.| Description: | Declare the header field which should be parsed for client IP addresses |
|---|---|
| Syntax: | RemoteIPHeader header-field |
| Context: | server config, virtual host |
| Status: | Base |
| Module: | mod_remoteip |
The RemoteIPHeader directive triggers
+ mod_remoteip to treat the value of the specified
+ header-field header as the client IP address, or list
+ of intermediate client IP addresses, subject to further configuration
+ of the RemoteIPInternalProxy and
+ RemoteIPTrustedProxy directives. Unless these
+ other directives are used, mod_remoteip will trust all
+ hosts presenting a RemoteIPHeader IP value.
+ RemoteIPHeader X-Client-IP
+
+ RemoteIPHeader X-Forwarded-For
+
| Description: | Declare client intranet IP addresses trusted to present the RemoteIPHeader value |
|---|---|
| Syntax: | RemoteIPInternalProxy proxy-ip|proxy-ip/subnet|hostname ... |
| Context: | server config, virtual host |
| Status: | Base |
| Module: | mod_remoteip |
The RemoteIPInternalProxy directive adds one
+ or more addresses (or address blocks) to trust as presenting a valid
+ RemoteIPHeader value of the client IP. Unlike the
+ RemoteIPTrustedProxy directive, any IP address
+ presented in this header, including private intranet addresses, are
+ trusted when passed from these proxies.
+ RemoteIPHeader X-Client-IP
+ RemoteIPTrustedProxy 10.0.2.0/24
+ RemoteIPTrustedProxy gateway.localdomain
+
| Description: | Declare client intranet IP addresses trusted to present the RemoteIPHeader value |
|---|---|
| Syntax: | RemoteIPInternalProxyList filename |
| Context: | server config, virtual host |
| Status: | Base |
| Module: | mod_remoteip |
The RemoteIPInternalProxyList directive specifies
+ a file parsed at startup, and builds a list of addresses (or address blocks)
+ to trust as presenting a valid RemoteIPHeader value of the client IP.
The '#' hash character designates a comment line, otherwise
+ each whitespace or newline seperated entry is processed identically to
+ the RemoteIPInternalProxy directive.
+ RemoteIPHeader X-Client-IP
+ RemoteIPTrustedProxyList conf/trusted-proxies.lst
+
+ # Our internally trusted proxies;
+ 10.0.2.0/24 #Everyone in the testing group
+ gateway.localdomain #The front end balancer
+
| Description: | Declare the header field which will record all intermediate IP addresses |
|---|---|
| Syntax: | RemoteIPProxiesHeader HeaderFieldName |
| Context: | server config, virtual host |
| Status: | Base |
| Module: | mod_remoteip |
The RemoteIPProxiesHeader directive specifies
+ a header into which mod_remoteip will collect a list of
+ all of the intermediate client IP addresses trusted to resolve the actual
+ remote IP. Note that intermediate RemoteIPTrustedProxy
+ addresses are recorded in this header, while any intermediate
+ RemoteIPInternalProxy addresses are discarded.
+ RemoteIPHeader X-Forwarded-For
+ RemoteIPProxiesHeader X-Forwarded-By
+
| Description: | Declare client intranet IP addresses trusted to present the RemoteIPHeader value |
|---|---|
| Syntax: | RemoteIPTrustedProxy proxy-ip|proxy-ip/subnet|hostname ... |
| Context: | server config, virtual host |
| Status: | Base |
| Module: | mod_remoteip |
The RemoteIPTrustedProxy directive adds one
+ or more addresses (or address blocks) to trust as presenting a valid
+ RemoteIPHeader value of the client IP. Unlike the
+ RemoteIPInternalProxy directive, any intranet
+ or private IP address reported by such proxies, including the 10/8, 172.16/12,
+ 192.168/16, 169.254/16 and 127/8 blocks (or outside of the IPv6 public
+ 2000::/3 block) are not trusted as the remote IP, and are left in the
+ RemoteIPHeader header's value.
+ RemoteIPHeader X-Forwarded-For
+ RemoteIPTrustedProxy 10.0.2.16/28
+ RemoteIPTrustedProxy proxy.example.com
+
| Description: | Declare client intranet IP addresses trusted to present the RemoteIPHeader value |
|---|---|
| Syntax: | RemoteIPTrustedProxyList filename |
| Context: | server config, virtual host |
| Status: | Base |
| Module: | mod_remoteip |
The RemoteIPTrustedProxyList directive specifies
+ a file parsed at startup, and builds a list of addresses (or address blocks)
+ to trust as presenting a valid RemoteIPHeader value of the client IP.
The '#' hash character designates a comment line, otherwise
+ each whitespace or newline seperated entry is processed identically to
+ the RemoteIPTrustedProxy directive.
+ RemoteIPHeader X-Forwarded-For
+ RemoteIPTrustedProxyList conf/trusted-proxies.lst
+
+ # Identified external proxies;
+ 192.0.2.16/28 #wap phone group of proxies
+ proxy.isp.example.com #some well known ISP
+
Available Languages: en
+Serveur Apache HTTP Version 2.3
-Cette page contient la liste des éléments actuellement disponibles de -la Documentation du serveur HTTP Apache Version -2.3.
-
Notes de version Utilisation du serveur HTTP Apache Documentation des serveurs virtuels Apache Guide de réécriture d'URLs Chiffrement SSL/TLS avec Apache Guides, Tutoriels, and Recettes Notes spécifiques à certains systèmes Le serveur HTTP Apache et ses programmes associés Documentations diverses sur Apache Modules Apache Documentation du développeur Glossaire et IndexServeur Apache HTTP Version 2.3
+Cette page contient la liste des éléments actuellement disponibles de +la Documentation du serveur HTTP Apache Version +2.3.
+ Notes de version Utilisation du serveur HTTP Apache Documentation des serveurs virtuels Apache Guide de réécriture d'URLs Chiffrement SSL/TLS avec Apache Guides, Tutoriels, and Recettes Notes spécifiques à certains systèmes Le serveur HTTP Apache et ses programmes associés Documentations diverses sur Apache Modules Apache Documentation du développeur Glossaire et Index