</directivelist>
</related>
-<p>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,
+<p>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,
les conteneurs
<directive type="section" module="core">IfDefine</directive>, <directive
-type="section" module="core">IfModule</directive>, et
+type="section" module="core">IfModule</directive> et
<directive type="section" module="mod_version">IfVersion</directive> 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
+s'appliqueront à toutes les requêtes. Si leurs conditions ne sont pas vérifiées, les
directives qu'ils contiennent seront ignorées.</p>
<p>Le conteneur <directive type="section" module="core">IfDefine</directive>
contient des directives qui ne seront appliquées que si un paramètre approprié a
-été défini dans la ligne de commande de <program>httpd</program> ou via une
+été défini dans la ligne de commande de <program>httpd</program> ou à l'aide d'une
directive <directive module="core">Define</directive>. 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 : <code>httpd
--DClosedForNow</code>:</p>
+si le serveur est démarré en utilisant la ligne de commande : <code>httpd
+-DClosedForNow</code> :</p>
<highlight language="config">
<IfDefine ClosedForNow>
</highlight>
<p>Le conteneur <directive type="section" module="core">IfModule</directive>
-est similaire; les directives qu'il contient ne s'appliqueront que si
+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
dynamiquement et dans ce cas, la ligne <directive
module="mod_so">LoadModule</directive> 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
+plus haut dans le fichier de configuration. Ce conteneur ne doit être
+utilisé que dans le cas où votre fichier de configuration doit être valable
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
<directive type="section" module="mod_version">IfVersion</directive>
est similaire aux conteneurs <directive type="section"
module="core">IfDefine</directive> et <directive type="section"
-module="core">IfModule</directive>; les directives qu'il contient ne
-s'appliqueront que si une version particulière du serveur s'exécute. Ce
+module="core">IfModule</directive> ; 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
et configurations de httpd.</p>
</highlight>
<p><directive type="section" module="core">IfDefine</directive>,
-<directive type="section" module="core">IfModule</directive>, et
+<directive type="section" module="core">IfModule</directive> et
<directive type="section" module="mod_version">IfVersion</directive>
-peuvent inverser leur test conditionnel en le faisant précéder d'un "!".
+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.</p>
</section>
<p>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 httpd est situé dans <code>/usr/local/apache2</code> pour le système de
-fichiers UNIX, ou <code>"c:/Program Files/Apache Group/Apache2"</code> pour
-le système de fichiers Windows. (Notez que des slashes directs doivent
-toujours être utilisés comme séparateur de chemin
-dans les fichiers de configuration d'Apache httpd, 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 <code>/dir/</code> dans
-l'arborescence du site web correspond au chemin
-<code>/usr/local/apache2/htdocs/dir/</code> dans le système de fichiers pour
-une installation d'Apache httpd 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.</p>
+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 httpd est situé dans
+<code>/usr/local/apache2</code> pour le système de fichiers UNIX, ou
+<code>"c:/Program Files/Apache Group/Apache2"</code> pour le système de
+fichiers Windows (notez que des slashes directs doivent toujours être utilisés
+comme séparateur de chemin dans les fichiers de configuration d'Apache httpd,
+même sous Windows). Quant à l'arborescence du site web, il s'agit d'une vue de
+votre site telle que présentée par le serveur web et perçue par le client.
+Ainsi le chemin <code>/dir/</code> dans l'arborescence du site web correspond
+au chemin <code>/usr/local/apache2/htdocs/dir/</code> dans le système de
+fichiers pour une installation d'Apache httpd 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.</p>
<section id="filesystem"><title>Conteneurs de système de fichiers</title>
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 <a
-href="howto/htaccess.html">fichiers .htaccess</a>. Par exemple, avec la
+href="howto/htaccess.html">fichiers .htaccess</a>. Par exemple, avec la
configuration suivante, l'indexation sera activée pour le répertoire
<code>/var/web/dir1</code> et tous ses sous-répertoires.</p>
particuliers du système de fichiers, les sections
<directive type="section" module="core">Files</directive> et
<directive type="section" module="core">Directory</directive>
-peuvent être combinées. Par exemple, la configuration suivante va interdire
+peuvent être combinées. Par exemple, la configuration suivante va interdire
l'accès à <code>/var/web/dir1/private.html</code>,
<code>/var/web/dir1/subdir2/private.html</code>,
<code>/var/web/dir1/subdir3/private.html</code>, ainsi que toute instance de
<p>le conteneur <directive type="section" module="core">Location</directive>
et son équivalent acceptant les
-<glossary ref="regex">expressions rationnelles</glossary>, modifient quant à eux la
-configuration de parties de l'arborescence du site web. Par exemple, la
+<glossary ref="regex">expressions rationnelles</glossary> 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
commence par /private.
En particulier, l'interdiction s'appliquera aux requêtes pour :
<p>Le conteneur <directive type="section" module="core">Location</directive>
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 du serveur HTTP Apache fourni par le module
+À ce titre, l'exemple suivant montre comment faire correspondre une URL
+particulière à un gestionnaire interne du serveur HTTP Apache fourni par le module
<module>mod_status</module>.
Il n'est pas nécessaire de trouver un fichier nommé <code>server-status</code>
dans le système de fichiers.</p>
<p>Pour contrôler deux URLs imbriquées, on doit tenir compte de l'ordre
dans lequel certaines sections ou directives sont évaluées. Pour
<directive type="section" module="core">Location</directive>, on doit
-avoir :</p>
+avoir :</p>
<highlight language="config">
<Location "/foo">
</Location>
</Location>
</highlight>
<p>Les directives <directive type="section"
-module="mod_alias">Alias</directive>, quant à elles, sont évaluées vice-versa :</p>
+module="mod_alias">Alias</directive>, quant à elles, sont évaluées vice-versa :</p>
<highlight language="config">
Alias "/foo/bar" "/srv/www/uncommon/bar"
Alias "/foo" "/srv/www/common/foo"
</highlight>
<p>Ceci est aussi vrai pour les directives <directive
-module="mod_proxy">ProxyPass</directive> :</p>
+module="mod_proxy">ProxyPass</directive> :</p>
<highlight language="config">
ProxyPass "/special-area" "http://special.example.com" smax=5 max=10
ProxyPass "/" "balancer://mycluster/" stickysession=JSESSIONID|jsessionid nofailover=On
<section id="wildcards"><title>Caractères de remplacement
et expressions rationnelles</title>
-<p>Les conteneurs
-<directive type="section" module="core">Directory</directive>,
-<directive type="section" module="core">Files</directive>, et
-<directive type="section" module="core">Location</directive>
-peuvent utiliser des caractères de remplacement de style shell comme dans
-la fonction <code>fnmatch</code> de la bibliothèque C standard.
-Le caractère "*"
-correspond à toute séquence de caractères, "?" à un caractère seul,
-et "[<em>seq</em>]" à tout caractère contenu dans <em>seq</em>.
-Le caractère "/"
-ne peut pas faire l'objet d'un remplacement;
-il doit être spécifié explicitement.</p>
-
-<p>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 : <directive
-type="section" module="core">DirectoryMatch</directive>, <directive
-type="section" module="core">FilesMatch</directive>, et <directive
-type="section" module="core">LocationMatch</directive> acceptent les
-<glossary ref="regex">expressions rationnelles</glossary> 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 comprendre comment l'utilisation de
-conteneurs avec des expressions rationnelles va modifier la manière
-dont les directives sont appliquées.</p>
-
-<p>Un conteneur qui modifie la configuration de tous les
-répertoires utilisateurs à l'aide de caractères de remplacement
-mais sans utiliser
-les expressions rationnelles pourrait ressembler à ceci :</p>
+<p>Les conteneurs <directive type="section"
+module="core">Directory</directive>, <directive type="section"
+module="core">Files</directive> et <directive type="section"
+module="core">Location</directive> peuvent utiliser des caractères de
+remplacement de style shell comme dans la fonction <code>fnmatch</code> de la
+bibliothèque C standard. Le caractère « * » correspond à toute séquence de
+caractères, « ? » à un caractère seul, et « [<em>seq</em>] » à tout caractère
+contenu dans <em>seq</em>. Le caractère « / » ne peut pas faire l'objet d'un
+remplacement ; il doit être spécifié explicitement.</p>
+
+<p>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 : <directive type="section"
+module="core">DirectoryMatch</directive>, <directive type="section"
+module="core">FilesMatch</directive> et <directive type="section"
+module="core">LocationMatch</directive> acceptent les <glossary
+ref="regex">expressions rationnelles</glossary> 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 comprendre comment l'utilisation
+de conteneurs avec des expressions rationnelles va modifier la manière dont les
+directives sont appliquées.</p>
+
+<p>Un conteneur qui modifie la configuration de tous les répertoires
+utilisateurs à l'aide de caractères de remplacement mais sans utiliser les
+expressions rationnelles pourrait ressembler à ceci :</p>
<highlight language="config">
<Directory "/home/*/public_html">
<p>Avec les conteneurs utilisant les expressions rationnelles,
on peut interdire l'accès à de nombreux types de fichiers d'images
-simultanément :</p>
+simultanément :</p>
<highlight language="config">
+<FilesMatch "\.(?i:gif|jpe?g|png)$">
Require all denied
<p>Les expressions rationnelles contenant des <strong>groupes nommés et
des références arrières</strong> sont ajoutées à l'environnement avec
-leur nom en majuscules. Ceci permet de référencer des éléments de
+leur nom en majuscules. Cela permet de référencer des éléments de
chemins de fichiers et d'URLs depuis une <a
href="expr.html">expression</a> et au sein de modules comme
<module>mod_rewrite</module>.</p>
permet de modifier la configuration en fonction d'une condition qui peut
être définie sous la forme d'une expression booléenne. Dans l'exemple
suivant, l'accès est interdit si l'en-tête HTTP Referer ne commence pas
-par "http://www.example.com/".</p>
+par « http://www.example.com/ ».</p>
<highlight language="config">
<If "!(%{HTTP_REFERER} -strmatch 'http://www.example.com/*')">
Require all denied
Pour appliquer des directives à des objets qui résident dans le système de
fichiers, utilisez toujours un conteneur <directive type="section"
module="core">Directory</directive> ou <directive type="section"
-module="core">Files</directive>. Pour appliquer des directives à des objets
+module="core">Files</directive>. 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 <directive type="section"
module="core">Location</directive>.</p>
<p>Il ne faut jamais utiliser un conteneur <directive type="section"
module="core">Location</directive> 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
+objets du système de fichiers, car plusieurs emplacements de
+l'arborescence du site web (URLs) peuvent correspondre au même emplacement
du système de fichier, ce qui peut permettre de contourner vos restrictions.
Par exemple, imaginez la configuration suivante :</p>
</highlight>
<p>Elle fonctionne correctement si la requête appelle
-<code>http://yoursite.example.com/dir/</code>. 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
-<code>http://yoursite.example.com/DIR/</code>. Le conteneur <directive
-type="section" module="core">Directory</directive>, 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
-<directive type="section" module="core">Directory</directive> 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
-directive
-<directive module="core">Options</directive> appropriée.)</p>
+<code>http://yoursite.example.com/dir/</code>. 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
+<code>http://yoursite.example.com/DIR/</code>. Le conteneur <directive
+type="section" module="core">Directory</directive>, quant à lui, s'appliquera à
+tout contenu servi à partir de cet emplacement, 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 <directive type="section"
+module="core">Directory</directive> 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 directive <directive
+module="core">Options</directive> appropriée.</p>
<p>Si vous pensez que vous n'êtes pas concerné par ce problème
-parceque vous utilisez un système de fichiers sensible à la casse,
+parce que 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
+correspondre plusieurs emplacements de l'arborescence du site web au même
+emplacement 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
+Il y a cependant une exception à cette règle. Placer des restrictions de
configuration dans un conteneur <code><Location
-"/"></code> est tout à fait sans rique car ce conteneur va s'appliquer à
+"/"></code> est absolument sans rique car ce conteneur va s'appliquer à
toutes les requêtes sans tenir compte de l'URL spécifique.</p>
</section>
<section id="nesting"><title>Imbrication des sections</title>
-<p>Certains types de sections peuvent être imbriqués : d'une part, on peut
+<p>Certains types de sections peuvent être imbriqués : d'une part, on peut
utiliser les sections <directive type="section" module="core">Files</directive>
à l'intérieur des sections <directive type="section"
module="core">Directory</directive>, d'autre part, on peut utiliser les
<directive type="section" module="core">Location</directive> et <directive
type="section" module="core">Files</directive> (mais pas à l'intérieur d'une
autre section <directive type="section" module="core">If</directive>). Les
-valeurs des expressions rationnelles correspondant aux sections nommées se
+valeurs des expressions rationnelles correspondant aux sections citées se
comportent de manière identique.</p>
<p>Les sections imbriquées sont fusionnées après les sections
<p>Le conteneur <directive type="section" module="core">VirtualHost</directive>
contient des directives qui s'appliquent à des serveurs virtuels spécifiques.
-Ceci s'avère utile pour servir les contenus de plusieurs serveurs virtuels à
+Cela s'avère utile pour servir les contenus de plusieurs serveurs virtuels à
partir de la même machine, chacun d'entre eux possédant une configuration
-différente.
Pour de plus amples informations, voir la <a
+différente. Pour de plus amples informations, voir la <a
href="vhosts/">Documentation sur les serveurs virtuels</a>.</p>
</section>
et <directive type="section" module="mod_proxy">ProxyMatch</directive>
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 <module>mod_proxy</module>.
+accédé à l'aide du serveur mandataire du module <module>mod_proxy</module>.
Par exemple, la configuration suivante n'autorisera qu'un sous-ensemble de
clients à accéder au site <code>www.example.com</code> en passant par le serveur
-mandataire :.</p>
+mandataire :</p>
<highlight language="config">
<Proxy "http://www.example.com/*">
</highlight>
</section>
-<section id="whatwhere"><title>Quelles sont les directives autorisées ?</title>
+<section id="whatwhere"><title>Quelles sont les directives autorisées ?</title>
<p>Pour déterminer quelles sont les directives autorisées pour tel type de
section de configuration, vérifiez le <a
<directive type="section" module="core">FilesMatch</directive>,
<directive type="section" module="core">Location</directive>,
<directive type="section" module="core">LocationMatch</directive>,
-<directive type="section" module="mod_proxy">Proxy</directive>,
+<directive type="section" module="mod_proxy">Proxy</directive>
et <directive type="section" module="mod_proxy">ProxyMatch</directive>.
-Il y a cependant quelques exceptions :</p>
+Il y a cependant quelques exceptions :</p>
<ul>
<li>La directive <directive module="core">AllowOverride</directive>
<li>Les <directive
module="core">Options</directive> <code>FollowSymLinks</code> et
-<code>SymLinksIfOwnerMatch</code> ne fonctionnent que dans les sections
+<code>SymLinksIfOwnerMatch</code> ne fonctionnent que dans les sections
<directive type="section" module="core">Directory</directive> ou les fichiers
<code>.htaccess</code>.</li>
des effets importants sur la manière dont les directives de configuration
sont interprétées.</p>
- <p>L'ordre dans lequel les sections sont appliquées est :</p>
+ <p>L'ordre dans lequel les sections sont appliquées est :</p>
<ol>
<li> Les sections <directive type="section"
- module="core">Directory</directive> (à l'exception des
- expressions rationnelles)
- et les fichiers <code>.htaccess</code> sont appliquées simultanément (avec
- la possibilité pour <code>.htaccess</code>, s'il y est autorisé, de
- prévaloir sur
- <directive type="section" module="core">Directory</directive>)</li>
-
- <li>Les sections
- <directive type="section" module="core">DirectoryMatch</directive>
- (et <code><Directory "~"></code>)</li>
+ module="core">Directory</directive> (à l'exception des expressions
+ rationnelles) et les fichiers <code>.htaccess</code> sont appliquées
+ simultanément (avec la possibilité pour <code>.htaccess</code>, s'il y est
+ autorisé, de prévaloir sur <directive type="section"
+ module="core">Directory</directive>)</li>
<li>Les sections <directive type="section"
- module="core">Files</directive> et <directive
- type="section" module="core">FilesMatch</directive> sont appliquées
- simultanément</li>
+ module="core">DirectoryMatch</directive> (et <code><Directory
+ "~"></code>)</li>
+
+ <li>Les sections <directive type="section" module="core">Files</directive>
+ et <directive type="section" module="core">FilesMatch</directive> sont
+ appliquées simultanément</li>
- <li>Les sections
- <directive type="section" module="core">Location</directive>
- et <directive type="section"
- module="core">LocationMatch</directive> sont appliquées
- simultanément</li>
+ <li>Les sections <directive type="section"
+ module="core">Location</directive> et <directive type="section"
+ module="core">LocationMatch</directive> sont appliquées simultanément</li>
<li>Les sections <directive type="section" module="core">If</directive>,
- même si elles sont incluses dans un des contextes précédents.
- </li>
+ même si elles sont incluses dans un des contextes précédents. </li>
</ol>
<p>Quelques remarques importantes :</p>
l'ordre dans lequel elles apparaissent dans les fichiers de configuration.
Par exemple, une requête pour <em>/foo/bar</em> correspondra à
<code><Location "/foo/bar"></code> et <code><Location
- "/foo"></code> (dans ce cas le groupe 4) : les deux sections seront
+ "/foo"></code> (dans ce cas le groupe 4) : les deux sections seront
évaluées mais selon l'ordre dans lequel elles apparaissent dans le fichier
- de configuration..</li>
+ de configuration.</li>
<li>Les sections <directive
type="section" module="core">Directory</directive> (groupe 1 ci-dessus)
sont traitées dans l'ordre du répertoire le plus court vers le plus long.
type="section" module="core">Directory</directive> s'appliquent au même
répertoire, elles sont traitées selon l'ordre dans lequel elles
apparaissent dans le fichier de configuration.</li>
- <li>Les sections de configuration incluses via la directive <directive
+ <li>Les sections de configuration incluses à laide de la directive <directive
module="core">Include</directive> sont traitées comme si elles se
trouvaient réellement dans le fichier qui les inclut à la position de la
directive
<li>Les sections situées à l'intérieur de sections <directive type="section"
module="core">VirtualHost</directive>
sont appliquées <em>après</em> 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.</li>
+ dehors de la définition du serveur virtuel, ce qui permet au serveur virtuel
+ de prévaloir sur la configuration du serveur global.</li>
<li>Quand la requête est servie par le module <module>mod_proxy</module>,
le conteneur <directive module="mod_proxy" type="section">Proxy</directive>
prend la place du conteneur <directive module="core"
<section id="relationship-module-configuration"><title>Interactions entre
modules et sections de configuration</title>
<p>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 <module>mod_rewrite</module> sont-elles interprétées ? La
+ configuration sont fusionnées : comment et quand les directives de modules
+ particuliers comme <module>mod_rewrite</module> 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 une commande au moment où elle est lue.</p>
<p>A l'exécution, le noyau de httpd parcourt 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
+ la requête actuelle. Lorsqu'une première section s'applique, elle est
+ considérée comme la configuration actuelle 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.</p>
<p>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
+ peut commencer : chaque module peut effectuer toute tâche qui lui incombe,
+ et pour déterminer de quelle manière il doit agir, il peut s'appuyer
sur le noyau de httpd pour retrouver sa configuration globale issue de la
fusion précédente.</p>
<p>Un exemple permet de mieux visualiser l'ensemble du processus. La
module="mod_headers">Header</directive> du module
<module>mod_headers</module> pour définir un en-tête HTTP spécifique. Quelle
valeur httpd va-t-il affecter à l'en-tête <code>CustomHeaderName</code> pour
- une requête vers <code>/example/index.html</code> ?
+ une requête vers <code>/example/index.html</code> ?
</p>
<highlight language="config">
nouveau, une nouvelle configuration est créée qui définit l'en-tête
<code>CustomHeaderName</code> avec la valeur <code>two</code>.</li>
<li><directive>FilesMatch</directive> ".*" s'applique, une nouvelle
- opportunité de fusion surgit, et l'en-tête <code>CustomHeaderName</code>
+ opportunité de fusion survient, et l'en-tête <code>CustomHeaderName</code>
est défini à la valeur <code>three</code>.</li>
<li>Finalement, au cours des étapes suivantes du traitement de la
requête HTTP, <module>mod_headers</module> sera sollicité, et il se
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...</li>
+ nécessaires ou obsolètes, etc.</li>
</ul>
<p>Ceci est aussi vrai pour les fichiers .htaccess car ils possèdent la même
</highlight>
-<p>Pour un exemple plus concret, considérez ce qui suit. Sans tenir compte
-de toute restriction d'accès placée dans les sections <directive module="core"
+<p>Pour un exemple plus concret, considérez ce qui suit. Sans tenir compte
+d'une quelconque restriction d'accès placée dans les sections <directive module="core"
type="section">Directory</directive>, la section <directive
module="core" type="section">Location</directive> sera
é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 !</p>
+En d'autres termes, l'ordre de la combinaison des sections est important ;
+soyez donc prudent !</p>
<highlight language="config">
<Location "/">
Require all granted
</Location>
-# Arrghs! Cette section <Directory> n'aura aucun effet
+# Grrrr ! Cette section <Directory> n'aura aucun effet
<Directory "/">
<RequireAll>
Require all granted
projects / thirdparty / apache / httpd.git / commitdiff
