From: Lucien Gentis Date: Sun, 28 Feb 2016 14:57:10 +0000 (+0000) Subject: XML update. X-Git-Tag: 2.2.32~146 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=a5ae6472642844be6395be32e59ef0b025957f86;p=thirdparty%2Fapache%2Fhttpd.git XML update. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x@1732750 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/sections.xml.fr b/docs/manual/sections.xml.fr index 15cfdd49cec..0242ac4c2d5 100644 --- a/docs/manual/sections.xml.fr +++ b/docs/manual/sections.xml.fr @@ -1,7 +1,7 @@ - + - + @@ -28,10 +28,10 @@

Les directives des fichiers de configuration peuvent s'appliquer -au serveur dans son ensemble, ou seulement à des répertoires, fichiers, hôtes, -ou URLs particuliers. Ce document décrit comment utiliser les conteneurs de +au serveur dans son ensemble, ou seulement à des répertoires, fichiers, hôtes, +ou URLs particuliers. Ce document décrit comment utiliser les conteneurs de sections de configuration ou les fichiers .htaccess pour -modifier la portée des directives de configuration.

+modifier la portée des directives de configuration.
Types de conteneurs de sections de @@ -60,317 +60,315 @@ configuration

Il existe deux grands types de conteneurs. La plupart des conteneurs sont -évalués pour chaque requête. Les directives qu'ils contiennent s'appliquent -seulement aux requêtes qui sont concernées par le conteneur. En revanche, +évalués pour chaque requête. Les directives qu'ils contiennent s'appliquent +seulement aux requêtes qui sont concernées par le conteneur. En revanche, les conteneurs IfDefine, IfModule, et IfVersion sont -évalués seulement au démarrage et au redémarrage du serveur. -Si leurs conditions sont vérifiées au démarrage, les directives qu'ils contiennent -s'appliqueront à toutes les requêtes. Si leurs conditions ne sont pas vérifiées, les -directives qu'ils contiennent seront ignorées.

+évalués seulement au démarrage et au redémarrage du serveur. +Si leurs conditions sont vérifiées au démarrage, les directives qu'ils contiennent +s'appliqueront à toutes les requêtes. Si leurs conditions ne sont pas vérifiées, les +directives qu'ils contiennent seront ignorées.

Le conteneur IfDefine -contient des directives qui ne seront appliquées que si un paramètre -approprié a été défini dans la ligne de commande de httpd. +contient des directives qui ne seront appliquées que si un paramètre +approprié a été défini dans la ligne de commande de httpd. Par exemple, -avec la configuration suivante, toutes les requêtes seront redirigées vers -un autre site si le serveur est démarré en utilisant la ligne de commande : +avec la configuration suivante, toutes les requêtes seront redirigées vers +un autre site si le serveur est démarré en utilisant la ligne de commande : httpd -DClosedForNow:

- -<IfDefine ClosedForNow>
-Redirect / http://otherserver.example.com/
+ +<IfDefine ClosedForNow> + Redirect / http://otherserver.example.com/ </IfDefine> - +

Le conteneur IfModule est similaire; les directives qu'il contient ne s'appliqueront que si un module particulier est disponible au niveau du serveur. -Le module doit être soit compilé statiquement dans le serveur, soit +Le module doit être soit compilé statiquement dans le serveur, soit dynamiquement et dans ce cas, la ligne LoadModule correspondante doit apparaître -plus haut dans le fichier de configuration. Ce conteneur ne doit être -utilisé que dans le cas où votre fichier de configuration doit fonctionner -indépendamment de la présence ou de l'absence de certains modules. +module="mod_so">LoadModule correspondante doit apparaître +plus haut dans le fichier de configuration. Ce conteneur ne doit être +utilisé que dans le cas où votre fichier de configuration doit fonctionner +indépendamment de la présence ou de l'absence de certains modules. Il ne doit pas contenir de directives que vous souhaitez voir s'appliquer -systématiquement, car vous pouvez perdre ainsi de précieux messages d'erreur -à propos de modules manquants.

+systématiquement, car vous pouvez perdre ainsi de précieux messages d'erreur +à propos de modules manquants.

Dans l'exemple suivant, la directive MimeMagicFile ne s'appliquera que si le module mod_mime_magic est disponible.

- -<IfModule mod_mime_magic.c>
-MimeMagicFile conf/magic
+ +<IfModule mod_mime_magic.c> + MimeMagicFile conf/magic </IfModule> - +

Le conteneur IfVersion est similaire aux conteneurs IfDefine et IfModule; les directives qu'il contient ne -s'appliqueront que si une version particulière du serveur s'exécute. Ce -conteneur a été conçu pour une utilisation dans les suites de tests -et les grands réseaux qui doivent prendre en compte différentes versions +s'appliqueront que si une version particulière du serveur s'exécute. Ce +conteneur a été conçu pour une utilisation dans les suites de tests +et les grands réseaux qui doivent prendre en compte différentes versions et configurations de httpd.

- - <IfVersion >= 2.1>
- - # les directives situées ici ne s'appliquent que si la version
- # est supérieure ou égale à 2.1.0.
- - </IfVersion> - + +<IfVersion >= 2.1> + # les directives situées ici ne s'appliquent que si la version + # est supérieure ou égale à 2.1.0. +</IfVersion> +

IfDefine, IfModule, et IfVersion -peuvent inverser leur test conditionnel en le faisant précéder d'un "!". -De plus, ces sections peuvent être imbriquées afin de définir des restrictions +peuvent inverser leur test conditionnel en le faisant précéder d'un "!". +De plus, ces sections peuvent être imbriquées afin de définir des restrictions plus complexes.

-
Système de fichiers et +<section id="file-and-web"><title>Système de fichiers et arborescence du site web -

Les conteneurs de sections de configuration les plus couramment utilisés -sont ceux qui modifient la configuration de points particuliers du système de +

Les conteneurs de sections de configuration les plus couramment utilisés +sont ceux qui modifient la configuration de points particuliers du système de fichiers ou de l'arborescence du site web. Tout d'abord, il est important de -comprendre la différence entre les deux. Le système de fichiers est une vue -de vos disques tels qu'ils sont perçus par votre système d'exploitation. -Par exemple, avec une installation par défaut, -Apache est situé dans /usr/local/apache2 pour le système de +comprendre la différence entre les deux. Le système de fichiers est une vue +de vos disques tels qu'ils sont perçus par votre système d'exploitation. +Par exemple, avec une installation par défaut, +Apache est situé dans /usr/local/apache2 pour le système de fichiers UNIX, ou "c:/Program Files/Apache Group/Apache2" pour -le système de fichiers Windows. (Notez que des slashes directs doivent -toujours être utilisés comme séparateur de chemin dans Apache, même sous -Windows.) Quant à +le système de fichiers Windows. (Notez que des slashes directs doivent +toujours être utilisés comme séparateur de chemin dans Apache, même sous +Windows.) Quant à l'arborescence du site web, il s'agit d'une vue de votre site -tel que présenté par le -serveur web et perçue par le client. Ainsi le chemin /dir/ dans +tel que présenté par le +serveur web et perçue par le client. Ainsi le chemin /dir/ dans l'arborescence du site web correspond au chemin -/usr/local/apache2/htdocs/dir/ dans le système de fichiers pour -une installation d'Apache par défaut sous UNIX. +/usr/local/apache2/htdocs/dir/ dans le système de fichiers pour +une installation d'Apache par défaut sous UNIX. En outre, l'arborescence du site web n'a pas besoin de correspondre en permanence au -système de fichiers, car les pages web peuvent être générées dynamiquement -à partir de bases de données ou d'autres emplacements.

+système de fichiers, car les pages web peuvent être générées dynamiquement +à partir de bases de données ou d'autres emplacements.

-
Conteneurs de système de fichiers +
Conteneurs de système de fichiers

Les conteneurs Directory et Files, -ainsi que leurs équivalents acceptant les +ainsi que leurs équivalents acceptant les expressions rationnelles, -appliquent des directives à certaines parties du système de fichiers. +appliquent des directives à certaines parties du système de fichiers. Les directives contenues dans une section Directory s'appliquent au répertoire -précisé, ainsi qu'à tous ses sous-répertoires et aux fichiers que ces +type="section" module="core">Directory s'appliquent au répertoire +précisé, ainsi qu'à tous ses sous-répertoires et aux fichiers que ces derniers contiennent. -Le même effet peut être obtenu en utilisant les fichiers .htaccess. Par exemple, avec la -configuration suivante, l'indexation sera activée pour le répertoire -/var/web/dir1 et tous ses sous-répertoires.

+configuration suivante, l'indexation sera activée pour le répertoire +/var/web/dir1 et tous ses sous-répertoires.

- -<Directory /var/web/dir1>
-Options +Indexes
+ +<Directory /var/web/dir1> + Options +Indexes </Directory> - +

Les directives contenues dans une section Files s'appliquent à tout fichier -avec le nom spécifié, quel que soit le répertoire dans lequel il se trouve. +module="core">Files s'appliquent à tout fichier +avec le nom spécifié, quel que soit le répertoire dans lequel il se trouve. Ainsi par exemple, les directives de configuration suivantes, si elles sont -placées dans la section principale du fichier de configuration, vont interdire -l'accès à tout fichier nommé private.html quel que soit -l'endroit où il se trouve.

- - -<Files private.html>
-Order allow,deny
-Deny from all
+placées dans la section principale du fichier de configuration, vont interdire +l'accès à tout fichier nommé private.html quel que soit +l'endroit où il se trouve.

+ + +<Files private.html> + Order allow,deny + Deny from all </Files> - + -

Pour faire référence à des fichiers qui se trouvent en des points -particuliers du système de fichiers, les sections +

Pour faire référence à des fichiers qui se trouvent en des points +particuliers du système de fichiers, les sections Files et Directory -peuvent être combinées. Par exemple, la configuration suivante va interdire -l'accès à /var/web/dir1/private.html, +peuvent être combinées. Par exemple, la configuration suivante va interdire +l'accès à /var/web/dir1/private.html, /var/web/dir1/subdir2/private.html, /var/web/dir1/subdir3/private.html, ainsi que toute instance de private.html qui se trouve dans l'arborescence /var/web/dir1/.

- -<Directory /var/web/dir1>
-<Files private.html>
-Order allow,deny
-Deny from all
-</Files>
+ +<Directory /var/web/dir1> + <Files private.html> + Order allow,deny + Deny from all + </Files> </Directory> - +
Conteneurs de l'arborescence du site web

le conteneur Location -et son équivalent acceptant les -expressions rationnelles, modifient quant à eux la +et son équivalent acceptant les +expressions rationnelles, modifient quant à eux la configuration de parties de l'arborescence du site web. Par exemple, la -configuration suivante interdit l'accès à toute URL dont la partie chemin +configuration suivante interdit l'accès à toute URL dont la partie chemin commence par /private. -En particulier, l'interdiction s'appliquera aux requêtes pour : +En particulier, l'interdiction s'appliquera aux requêtes pour : http://yoursite.example.com/private, http://yoursite.example.com/private123, et -http://yoursite.example.com/private/dir/file.html ainsi qu'à -toute requête commençant par la chaîne de caractères /private.

+http://yoursite.example.com/private/dir/file.html ainsi qu'à +toute requête commençant par la chaîne de caractères /private.

- -<LocationMatch ^/private>
-Order Allow,Deny
-Deny from all
+ +<LocationMatch ^/private> + Order Allow,Deny + Deny from all </LocationMatch> - +

Le conteneur Location -n'a pas besoin de faire référence à un élément du système de fichiers. -Par exemple, l'exemple suivant montre comment faire référence à une URL -particulière vers un gestionnaire interne d'Apache fourni par le module +n'a pas besoin de faire référence à un élément du système de fichiers. +Par exemple, l'exemple suivant montre comment faire référence à une URL +particulière vers un gestionnaire interne d'Apache fourni par le module mod_status. -Il n'est pas nécessaire de trouver un fichier nommé server-status -dans le système de fichiers.

+Il n'est pas nécessaire de trouver un fichier nommé server-status +dans le système de fichiers.

- -<Location /server-status>
-SetHandler server-status
+ +<Location /server-status> + SetHandler server-status </Location> - +
-
Caractères de remplacement +<section id="wildcards"><title>Caractères de remplacement et expressions rationnelles

Les conteneurs Directory, Files, et Location -peuvent utiliser des caractères de remplacement de style shell comme dans -la fonction fnmatch de la bibliothèque C standard. -Le caractère "*" -correspond à toute séquence de caractères, "?" à un caractère seul, -et "[seq]" à tout caractère contenu dans seq. -Le caractère "/" +peuvent utiliser des caractères de remplacement de style shell comme dans +la fonction fnmatch de la bibliothèque C standard. +Le caractère "*" +correspond à toute séquence de caractères, "?" à un caractère seul, +et "[seq]" à tout caractère contenu dans seq. +Le caractère "/" ne peut pas faire l'objet d'un remplacement; -il doit être spécifié explicitement.

+il doit être spécifié explicitement.

-

Si une définition des critères de correspondance -encore plus souple est nécessaire, chaque conteneur -possède son équivalent acceptant les expressions rationnelles : Si une définition des critères de correspondance +encore plus souple est nécessaire, chaque conteneur +possède son équivalent acceptant les expressions rationnelles : DirectoryMatch, FilesMatch, et LocationMatch acceptent les expressions rationnelles compatibles Perl -pour définir les critères de correspondance. Mais voyez plus loin la section -à propos de la combinaison des sections de configuration +pour définir les critères de correspondance. Mais voyez plus loin la section +à propos de la combinaison des sections de configuration pour comprendre comment l'utilisation de -conteneurs avec des expressions rationnelles va modifier la manière -dont les directives sont appliquées.

+conteneurs avec des expressions rationnelles va modifier la manière +dont les directives sont appliquées.

Un conteneur qui modifie la configuration de tous les -répertoires utilisateurs à l'aide de caractères de remplacement +répertoires utilisateurs à l'aide de caractères de remplacement mais sans utiliser -les expressions rationnelles pourrait ressembler à ceci :

+les expressions rationnelles pourrait ressembler à ceci :

- -<Directory /home/*/public_html>
-Options Indexes
+ +<Directory /home/*/public_html> + Options Indexes </Directory> - +

Avec les conteneurs utilisant les expressions rationnelles, -on peut interdire l'accès à de nombreux types de fichiers d'images -simultanément :

- -<FilesMatch \.(?i:gif|jpe?g|png)$>
-Order allow,deny
-Deny from all
+on peut interdire l'accès à de nombreux types de fichiers d'images +simultanément :

+ +<FilesMatch \.(?i:gif|jpe?g|png)$> + Order allow,deny + Deny from all </FilesMatch> - +
Que faut-il utiliser et quand ? -

Choisir entre des conteneurs de système de fichiers et des conteneurs -d'arborescence du site web est vraiment très simple. -Pour appliquer des directives à des objets qui résident dans le système de +

Choisir entre des conteneurs de système de fichiers et des conteneurs +d'arborescence du site web est vraiment très simple. +Pour appliquer des directives à des objets qui résident dans le système de fichiers, utilisez toujours un conteneur Directory ou Files. Pour appliquer des directives à des objets -qui ne résident pas dans le système de fichiers (comme une page web générée -par une base de données), utilisez un conteneur Files. Pour appliquer des directives à des objets +qui ne résident pas dans le système de fichiers (comme une page web générée +par une base de données), utilisez un conteneur Location.

Il ne faut jamais utiliser un conteneur Location pour restreindre l'accès à des -objets du système de fichiers, car plusieurs localisations de -l'arborescence du site web (URLs) peuvent correspondre à la même localisation -du système de fichier, ce qui peut permettre de contourner vos restrictions. +module="core">Location pour restreindre l'accès à des +objets du système de fichiers, car plusieurs localisations de +l'arborescence du site web (URLs) peuvent correspondre à la même localisation +du système de fichier, ce qui peut permettre de contourner vos restrictions. Par exemple, imaginez la configuration suivante :

- -<Location /dir/>
-Order allow,deny
-Deny from all
+ +<Location /dir/> + Order allow,deny + Deny from all </Location> - + -

Elle fonctionne correctement si la requête appelle +

Elle fonctionne correctement si la requête appelle http://yoursite.example.com/dir/. Mais que va-t-il se passer si -votre système de fichiers est insensible à la casse ? -Votre restriction va pouvoir être tout simplement contournée en envoyant une -requête sur +votre système de fichiers est insensible à la casse ? +Votre restriction va pouvoir être tout simplement contournée en envoyant une +requête sur http://yoursite.example.com/DIR/. Le conteneur Directory, quant à lui, s'appliquera -à tout contenu servi à partir de cette localisation, -sans tenir compte de la manière dont il est appelé. -(Les liens du système de fichiers constituent une exception. -Le même répertoire peut être placé dans plusieurs parties du système de +type="section" module="core">Directory, quant à lui, s'appliquera +à tout contenu servi à partir de cette localisation, +sans tenir compte de la manière dont il est appelé. +(Les liens du système de fichiers constituent une exception. +Le même répertoire peut être placé dans plusieurs parties du système de fichiers en utilisant des liens symboliques. Le conteneur Directory va suivre le -lien symbolique sans modifier le nom du chemin. Par conséquent, pour plus de -sécurité, les liens symboliques doivent être désactivés à l'aide de la +lien symbolique sans modifier le nom du chemin. Par conséquent, pour plus de +sécurité, les liens symboliques doivent être désactivés à l'aide de la directive -Options appropriée.)

- -

Si vous pensez que vous n'êtes pas concerné par ce problème -parceque vous utilisez un système de fichiers sensible à la casse, -gardez à l'esprit qu'il y a de nombreuses autres manières pour faire -correspondre plusieurs localisations de l'arborescence du site web à la même -localisation du système de fichiers. C'est pourquoi vous devez autant que -possible toujours utiliser les conteneurs de système de fichiers. -Il y a cependant une exception à cette règle. Placer des restrictions de +Options appropriée.)

+ +

Si vous pensez que vous n'êtes pas concerné par ce problème +parceque vous utilisez un système de fichiers sensible à la casse, +gardez à l'esprit qu'il y a de nombreuses autres manières pour faire +correspondre plusieurs localisations de l'arborescence du site web à la même +localisation du système de fichiers. C'est pourquoi vous devez autant que +possible toujours utiliser les conteneurs de système de fichiers. +Il y a cependant une exception à cette règle. Placer des restrictions de configuration dans un conteneur <Location -/> est tout à fait sans rique car ce conteneur va s'appliquer à -toutes les requêtes sans tenir compte de l'URL spécifique.

+/> est tout à fait sans rique car ce conteneur va s'appliquer à +toutes les requêtes sans tenir compte de l'URL spécifique.

-
Hôtes virtuels +
Hôtes virtuels

Le conteneur VirtualHost -contient des directives qui s'appliquent à des hôtes spécifiques. -Ceci s'avère utile pour servir des hôtes multiples à partir de la même machine, -chacun d'entre eux possédant une configuration différente. Pour de plus amples +contient des directives qui s'appliquent à des hôtes spécifiques. +Ceci s'avère utile pour servir des hôtes multiples à partir de la même machine, +chacun d'entre eux possédant une configuration différente. Pour de plus amples informations, -voir la Documentation sur les hôtes virtuels.

+voir la Documentation sur les hôtes virtuels.

Mandataire @@ -379,26 +377,27 @@ voir la Documentation sur les hôtes virtuels.

Proxy et ProxyMatch appliquent les directives de configuration qu'ils contiennent uniquement aux -sites qui correspondent à l'URL spécifiée et auxquels on a -accédé via le serveur mandataire du module mod_proxy. -Par exemple, la configuration suivante -va interdire l'utilisation du serveur proxy pour accéder au site -cnn.com.

- - -<Proxy http://cnn.com/*>
-Order allow,deny
-Deny from all
+sites qui correspondent à l'URL spécifiée et auxquels on a +accédé via le serveur mandataire du module mod_proxy. +Par exemple, la configuration suivante n'autorisera l'accès au site web +www.example.com via le serveur mandataire qu'à un sous-ensemble de +clients :

+ + +<Proxy "http://www.example.com/*"> + Order allow,deny + Allow from 192.168.1.104 192.168.1.205 + Deny from all </Proxy> - +
-
Quelles sont les directives autorisées ? +
Quelles sont les directives autorisées ? -

Pour déterminer quelles sont les directives autorisées pour tel type de -section de configuration, vérifiez le Pour déterminer quelles sont les directives autorisées pour tel type de +section de configuration, vérifiez le Contexte de la directive. -Tout ce qui est autorisé dans les sections +Tout ce qui est autorisé dans les sections Directory l'est aussi d'un point de vue syntaxique dans les sections DirectoryMatch, @@ -421,29 +420,29 @@ module="core">Options FollowSymLinks et Directory ou les fichiers .htaccess. -

  • La directive Options ne peut pas être -utilisée dans les sections +
  • La directive Options ne peut pas être +utilisée dans les sections Files et FilesMatch.
    • -
    Comment les sections sont combinées entre elles +
    Comment les sections sont combinées entre elles -

    Les sections de configuration sont appliquées dans un ordre très particulier. -Il est important de savoir comment cet ordre est défini car il peut avoir -des effets importants sur la manière dont les directives de configuration -sont interprétées.

    +

    Les sections de configuration sont appliquées dans un ordre très particulier. +Il est important de savoir comment cet ordre est défini car il peut avoir +des effets importants sur la manière dont les directives de configuration +sont interprétées.

    -

    L'ordre dans lequel les sections sont combinées est :

    +

    L'ordre dans lequel les sections sont combinées est :

    1. Les sections Directory (à l'exception des + module="core">Directory (à l'exception des expressions rationnelles) - et les fichiers .htaccess sont appliqués simultanément (avec - la possibilité pour .htaccess, s'il y est autorisé, de - prévaloir sur + et les fichiers .htaccess sont appliqués simultanément (avec + la possibilité pour .htaccess, s'il y est autorisé, de + prévaloir sur Directory)
    2. Les sections @@ -452,112 +451,185 @@ sont interprétées.

    3. Les sections Files et FilesMatch sont appliquées - simultanément
      4. + type="section" module="core">FilesMatch sont appliquées + simultanément
    4. Les sections Location et LocationMatch sont appliquées - simultanément
      5. + module="core">LocationMatch sont appliquées + simultanément
    -

    Mises à part les sections Directory, chaque groupe est traité selon - l'ordre dans lequel il apparaît dans les fichiers de configuration. +

    Mises à part les sections Directory, chaque groupe est traité selon + l'ordre dans lequel il apparaît dans les fichiers de configuration. Les sections Directory (groupe 1 ci-dessus) - sont traitées dans l'ordre du répertoire le plus court vers le plus long. + sont traitées dans l'ordre du répertoire le plus court vers le plus long. Par exemple, <Directory /var/web/dir> sera - traité avant <Directory + traité avant <Directory /var/web/dir/subdir>. Si plusieurs sections Directory s'appliquent au même - répertoire, elles sont traitées selon l'ordre dans lequel elles + type="section" module="core">Directory s'appliquent au même + répertoire, elles sont traitées selon l'ordre dans lequel elles apparaissent dans le fichier de configuration. Les sections de configuration incluses via la directive Include sont traitées comme si elles se - trouvaient réellement dans le fichier qui les inclut à la position de la + module="core">Include sont traitées comme si elles se + trouvaient réellement dans le fichier qui les inclut à la position de la directive Include.

    -

    Les sections situées à l'intérieur de sections Les sections situées à l'intérieur de sections VirtualHost - sont appliquées après les sections correspondantes situées en - dehors de la définition de l'hôte virtuel, ce qui permet à l'hôte virtuel - de prévaloir sur la configuration du serveur principal.

    + sont appliquées après les sections correspondantes situées en + dehors de la définition de l'hôte virtuel, ce qui permet à l'hôte virtuel + de prévaloir sur la configuration du serveur principal.

    -

    Quand la requête est servie par le module mod_proxy, +

    Quand la requête est servie par le module mod_proxy, le conteneur Proxy prend la place du conteneur Directory dans l'ordre de traitement.

    -

    Les sections situées plus loin dans le fichier de configuration prévalent - sur celles qui les précèdent.

    - Note technique - Une séquence + Une séquence <Location>/<LocationMatch> - est réellement traitée juste avant la phase de traduction du nom - (où Aliases et DocumentRoots - sont utilisés pour faire correspondre les URLs aux noms de fichiers). - Les effets de cette séquence disparaissent totalement lorsque - la traduction est terminée. + est réellement traitée juste avant la phase de traduction du nom + (où Aliases et DocumentRoots + sont utilisés pour faire correspondre les URLs aux noms de fichiers). + Les effets de cette séquence disparaissent totalement lorsque + la traduction est terminée. +
    Interactions entre +modules et sections de configuration +

    Une question se pose souvent après avoir lu comment les sections de + configuration sont fusionnées : comment et quand les directives de modules + particuliers comme mod_rewrite sont-elles interprétées ? La + réponse n'est pas triviale et nécessite un approfondissement. Chaque module + httpd gère sa propre configuration, et chacune de ses directives dans + httpd.conf définit un élément de configuration dans un contexte particulier. + httpd n'exécute pas un commande au moment où elle est lue.

    +

    A l'exécution, le noyau de httpd parcours les sections de configuration + dans l'ordre décrit ci-dessus afin de déterminer lesquelles s'appliquent à + la requête courante. Lorsqu'une première section s'applique, elle est + considérée comme la configuration courante pour cette requête. Si une + section suivante s'applique aussi, chaque module qui possède des directives + dans chacune de ces sections a la possibilité de fusionner sa configuration + entre ces deux sections. Il en résulte une troisième configuration et le + processus de fusion se poursuit jusqu'à ce que toutes les sections de + configuration aient été évaluées.

    +

    Après l'étape précédente, le traitement proprement dit de la requête HTTP + peut commencer : chaque module peut effectuer toute tâche qui lui incombe, + et pour déterminer de quelle manière dont il doit agir, il peut s'appuyer + sur le noyau de httpd pour retrouver sa configuration globale issue de la + fusion précédente.

    +

    Un exemple permet de mieux visualiser l'ensemble du processus. la + configuration suivante utilise la directive Header du module + mod_headers pour définir un en-tête HTTP spécifique. Quelle + valeur httpd va-t-il affecter à l'en-tête CustomHeaderName pour + une requête vers /example/index.html ? +

    + + +<Directory "/"> + Header set CustomHeaderName one + <FilesMatch ".*"> + Header set CustomHeaderName three + </FilesMatch> +</Directory> + +<Directory "/example"> + Header set CustomHeaderName two +</Directory> + + +
      +
    • Directory "/" s'applique, et une configuration + initiale est créée qui définit l'en-tête CustomHeaderName + avec la valeur one.
      • +
    • Directory "/example" s'applique, et comme + mod_headers spécifie dans son code que + la valeur d'un en-tête doit être écrasée si ce dernier est défini à + nouveau, une nouvelle configuration est créée qui définit l'en-tête + CustomHeaderName avec la valeur two.
      • +
    • FilesMatch ".*" s'applique, une nouvelle + opportunité de fusion surgit, et l'en-tête CustomHeaderName + est défini à la valeur three.
      • +
    • Finalement, au cours des étapes suivantes du traitement de la + requête HTTP, mod_headers sera sollicité, et il se + basera sur la configuration qui a défini l'en-tête + CustomHeaderName à la valeur three. + mod_headers utilise normalement cette configuration pour + accomplir sa tâche, à savoir définir des en-têtes HTTP. Cela ne veut + cependant pas dire qu'un module ne peut pas effectuer des actions plus + complexes comme désactiver des directives car elle ne sont pas + nécessaires ou obsolètes, etc...
      • +
    + +

    Ceci est aussi vrai pour les fichiers .htaccess car ils possèdent la même + priorité que les sections Directory dans l'ordre de + fusion. Il faut bien comprendre que les sections de configuration comme + Directory et FilesMatch ne + sont pas comparables avec les directives spécifiques de modules comme + Header ou RewriteRule car elles agissent à des + niveaux différents. +

    +
    +
    Quelques exemples

    Voici un exemple imaginaire qui montre l'ordre de combinaison des sections. -En supposant qu'elles s'appliquent toutes à la requête, les directives de -cet exemple seront appliquées dans l'ordre suivant : A > B > C > D > +En supposant qu'elles s'appliquent toutes à la requête, les directives de +cet exemple seront appliquées dans l'ordre suivant : A > B > C > D > E.

    - -<Location />
    -E
    -</Location>
    -
    -<Files f.html>
    -D
    -</Files>
    -
    -<VirtualHost *>
    -<Directory /a/b>
    -B
    -</Directory>
    -</VirtualHost>
    -
    -<DirectoryMatch "^.*b/">
    -C
    -</DirectoryMatch>
    -
    -<Directory /a/b>
    -A
    -</Directory>
    -
    -     - -

    Pour un exemple plus concret, considérez ce qui suit. Sans tenir compte -de toute restriction d'accès placée dans les sections +<Location "/"> + E +</Location> + +<Files "f.html"> + D +</Files> + +<VirtualHost *> +<Directory "/a/b"> + B +</Directory> +</VirtualHost> + +<DirectoryMatch "^.*b$"> + C +</DirectoryMatch> + +<Directory "/a/b"> + A +</Directory> + + + +

    Pour un exemple plus concret, considérez ce qui suit. Sans tenir compte +de toute restriction d'accès placée dans les sections Directory, la section Location sera -évaluée en dernier et permettra un accès au serveur sans aucune restriction. +évaluée en dernier et permettra un accès au serveur sans aucune restriction. En d'autres termes, l'ordre de la combinaison des sections est important, soyez donc prudent !

    - -<Location />
    -Order deny,allow
    -Allow from all
    -</Location>
    -
    :if expand("%") == ""|browse confirm w|else|confirm w|endif - -# Arrghs! Cette section <Directory> n'aura aucun effet
    -<Directory />
    -Order allow,deny
    -Allow from all
    -Deny from badguy.example.com
    + +<Location "/"> + Require all granted +</Location> +# Arrghs! Cette section <Directory> n'aura aucun effet +<Directory "/"> + <RequireAll> + Require all granted + Require not host badguy.example.com + </RequireAll> </Directory> -     +