You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by lg...@apache.org on 2016/02/27 18:48:49 UTC
svn commit: r1732658 - in /httpd/httpd/branches/2.4.x/docs/manual:
mod/event.xml.fr sections.xml.fr
Author: lgentis
Date: Sat Feb 27 17:48:49 2016
New Revision: 1732658
URL: http://svn.apache.org/viewvc?rev=1732658&view=rev
Log:
XML updates.
Modified:
httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml.fr
httpd/httpd/branches/2.4.x/docs/manual/sections.xml.fr
Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml.fr?rev=1732658&r1=1732657&r2=1732658&view=diff
==============================================================================
--- httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml.fr (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/mod/event.xml.fr Sat Feb 27 17:48:49 2016
@@ -1,7 +1,7 @@
-<?xml version="1.0"?>
+<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1515476:1731251 (outdated) -->
+<!-- English Revision: 1731251 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
@@ -24,22 +24,18 @@
<modulesynopsis metafile="event.xml.meta">
<name>event</name>
-<description>Une variante du MPM <module>worker</module> conçue pour ne
+<description>Une variante du MPM <module>worker</module> conçue pour ne
mobiliser des threads que pour les connexions en cours de traitement</description>
<status>MPM</status>
<sourcefile>event.c</sourcefile>
<identifier>mpm_event_module</identifier>
<summary>
- <p>Le module multi-processus (MPM) <module>event</module> est conçu
- pour permettre le traitement d'un nombre accru de requêtes
- simultanées en déléguant certaines tâches à des threads de support,
- libérant par là-même le thread principal et lui permettant de
- traiter les nouvelles requêtes. Il s'inspire du MPM
- <module>worker</module> qui implémente un serveur hybride
- multi-processus/multi-threads. Les directives de configuration à
- l'exécution sont identiques à celles du MPM
- <module>worker</module>.</p>
+ <p>Le module multi-processus (MPM) <module>event</module> est conçu
+ pour permettre le traitement d'un nombre accru de requêtes
+ simultanées en déléguant certaines tâches
+ aux threads d'écoute, libérant par là -même les
+ threads de travail et leur permettant de traiter les nouvelles requêtes.</p>
<p>Pour utiliser le MPM <module>event</module>, ajoutez
<code>--with-mpm=event</code> aux arguments du script
@@ -50,78 +46,189 @@ mobiliser des threads que pour les conne
<seealso><a href="worker.html">Le MPM worker</a></seealso>
+<section id="event-worker-relationship"><title>Relations avec le MPM Worker</title>
+<p>Le MPM <module>event</module> s'inspire du MPM <module>worker</module> qui
+implémente un serveur hybride multi-processus et multi-threads. Un processus de
+contrôle unique (le parent) est chargé de lancer des processus enfants. Chaque
+processus enfant crée un nombre de threads serveurs défini via la directive
+<directive module="mpm_common">ThreadsPerChild</directive>, ainsi qu'un thread
+d'écoute qui surveille les requêtes entrantes et les distribue aux threads de
+travail pour traitement au fur et à mesure de leur arrivée.</p>
+
+<p>Les directives de configuration à l'exécution sont identiques à celles que
+propose le MPM <module>worker</module>, avec l'unique addition de la directive
+<directive>AsyncRequestWorkerFactor</directive>.</p>
+
+</section>
+
<section id="how-it-works"><title>Comment tout cela fonctionne</title>
- <p>Ce MPM essaie de résoudre le 'problème keep alive' de HTTP.
- Lorsqu'un client a soumis une première requête, il peut garder la
- connexion ouverte, et envoyer les requêtes suivantes en utilisant le
- même socket. Ceci permet de réduire de manière significative la
- surcharge due à la création de connexions TCP.
- Cependant, le serveur HTTP Apache
- mobilise en principe à cet effet un processus/thread enfant en
- attente des données du client, ce qui amène son propre lot
- d'inconvénients. Pour résoudre ce problème, <module>event</module>
- utilise un thread dédié qui gère les sockets en
- écoute, tous les sockets en état Keep Alive, et les
- sockets où les filtres gestionnaires et de protocole ont
- fait leur travail et pour lesquels la seule chose restant à faire
- consiste à envoyer les données au client. La page d'état de
- <module>mod_status</module> montre les connexions qui se trouvent
- dans les situations mentionnées.</p>
-
- <p>Le gestionnaire de connexion amélioré peut ne pas
- fonctionner pour les filtres de connexion qui se déclarent eux-mêmes
- comme incompatibles avec le MPM event. Dans ce cas, le MPM event
- adopte le comportement du MPM <module>worker</module> et
- réserve un thread par connexion. Tous les modules fournis
- avec le serveur sont compatibles avec le MPM event.</p>
-
- <p>Une restriction similaire existe pour les requêtes qui utilisent
- un filtre en sortie qui doit lire et/ou modifier l'ensemble du corps
- de réponse, comme dans le cas de mod_ssl, mod_deflate, ou
- mod_include. Si la connexion avec le client se bloque pendant que le
- filtre traite les données, et si la quantité de données générée par
- ce filtre est trop importante pour être mise en tampon mémoire, le
- thread utilisé pour la requête n'est pas libéré pendant que httpd
- attend que toutes les données restantes aient été transmises au
- client.</p>
-
- <p>Le MPM présuppose que l'implémentation <code>apr_pollset</code>
- sous-jacente est raisonnablement sûre du point de vue des threads.
- Ceci permet au MPM d'éviter un verrouillage de haut niveau excessif,
- ou de devoir activer le thread en écoute afin de lui envoyer un
- socket keep alive. Tout ceci n'est actuellement compatible qu'avec
- KQueue et EPoll.</p>
+
+ <p>Ce module MPM tente de résoudre le "problème keep
+ alive" de HTTP. Lorsqu'un client a effectué une première requête, il peut
+ garder la connexion ouverte et envoyer les requêtes suivante en utilisant le
+ même socket, ce qui diminue considérablement la charge qui aurait été
+ induite par la création de nouvelles connexions TCP. Cependant, le
+ fonctionnement du serveur HTTP Apache impose de réserver un couple processus
+ enfant/thread pour attendre les données en provenance du client, ce qui
+ présente certains inconvénients.
+ Pour résoudre ce problème, le MPM Event utilise un thread d'écoute dédié
+ pour chaque processus pour gérer les sockets d'écoute, tous les sockets qui
+ sont dans un état de connexion persistante, les sockets où les
+ filtres de gestionnaire et de protocole ont fait leur travail, et ceux pour
+ lesquels la seule chose restant à faire est l'envoi des données au client.
+ </p>
+
+ <p>La directive <directive>AsyncRequestWorkerFactor</directive> permet de
+ définir le nombre total de connexions qu'un bloc processus/thread peut
+ gérer.</p>
+
+ <section id="async-connections"><title>Connexions asynchrones</title>
+ <p>Avec les MPM précédents, les connexions asynchrones nécessitaient
+ un thread de travail dédié, mais ce n'est plus le cas avec le MPM Event.
+ La page d'état de <module>mod_status</module> montre de nouvelles
+ colonnes dans la section "Async connections" :</p>
+ <dl>
+ <dt>Writing</dt>
+ <dd>Lors de l'envoi de la réponse au client, il peut arriver que le
+ tampon d'écriture TCP soit plein si la connexion est trop lente. Si
+ cela se produit, une instruction <code>write()</code> vers le socket
+ renvoie en général <code>EWOULDBLOCK</code> ou <code>EAGAIN</code>
+ pour que l'on puisse y écrire à nouveau après un certain temps
+ d'inactivité. Le thread de travail qui utilise le socket doit alors
+ être en mesure de récupérer la tâche en attente et la restituer au
+ thread d'écoute qui, à son tour, la réattribuera au premier thread
+ de travail disponible, lorsqu'un évènement sera généré pour le socket
+ (par exemple, "il est maintenant possible d'écrire dans le socket").
+ Veuillez vous reporter à la section à propos des limitations pour
+ plus de détails.
+ </dd>
+
+ <dt>Keep-alive</dt>
+ <dd>La gestion des connexions persistantes constitue la principale
+ amélioration par rapport au MPM Worker. Lorsqu'un thread de travail
+ a terminé l'envoi d'une réponse à un client, il peut restituer la
+ gestion du socket au thread d'écoute, qui à son tour va attendre un
+ évènement en provenance du système d'exploitation comme "le socket
+ est lisible". Si une nouvelle requête arrive en provenance du
+ client, le thread d'écoute l'attribuera au premier thread de travail
+ disponible. Inversement, si le délai <directive
+ module="core">KeepAliveTimeout</directive> est atteint, le socket
+ sera fermé par le thread d'écoute. Les threads de travail n'ont
+ donc plus à s'occuper des sockets inactifs et ils peuvent être
+ réutilisés pour traiter d'autres requêtes.</dd>
+
+ <dt>Closing</dt>
+ <dd>Parfois, le MPM doit effectuer une fermeture progressive, c'est
+ à dire envoyer au client une erreur survenue précédemment alors que
+ ce dernier est en train de transmettre des données à httpd. Envoyer la réponse et
+ fermer immédiatement la connexion n'est pas une bonne solution car
+ le client (qui est encore en train d'envoyer le reste de la requête)
+ verrait sa connexion réinitialisée et ne pourrait pas lire la
+ réponse de httpd. Si cela se produit, httpd essaie donc de lire le
+ reste de la requête afin de permettre au client de lire la réponse
+ entièrement. La fermeture progressive est limitée dans le temps,
+ mais elle peut tout de même être assez longue, si bien qu'il est
+ intéressant qu'un thread de travail puisse se décharger de cette
+ tâche sur le thread d'écoute.</dd>
+ </dl>
+
+ <p>Ces améliorations sont disponible pour les connexions HTTP ou HTTPS.</p>
+
+ </section>
+
+ <section id="limitations"><title>Limitations</title>
+ <p>La gestion améliorée des connexions peut ne pas fonctionner pour
+ certains filtres de connexion qui se sont déclarés eux-mêmes
+ incompatibles avec le MPM Event. Dans ce cas, le MPM Event réadoptera le
+ comportement du MPM <module>worker</module> et réservera un thread de
+ travail par connexion. Notez que tous les modules inclus dans la
+ distribution du serveur httpd sont compatibles avec le MPM Event.</p>
+
+ <p>Une restriction similaire apparaît lorsqu'une requête utilise un
+ filtre en sortie qui doit pouvoir lire et/ou modifier la totalité du
+ corps de la réponse. Si la connexion avec le client se bloque pendant
+ que le filtre traite les données, et si la quantité de données produites
+ par le filtre est trop importante pour être stockée en mémoire, le
+ thread utilisé pour la requête n'est pas libéré pendant que httpd attend
+ que les données soient transmises au client.<br />
+ Pour illustrer ce cas de figure, nous pouvons envisager les deux
+ situations suivantes : servir une ressource statique (comme un fichier
+ CSS) ou servir un contenu issu d'un programme FCGI/CGI ou d'un serveur
+ mandaté. La première situation est prévisible ; en effet, le MPM Event a
+ une parfaite visibilité sur la fin du contenu, et il peut utiliser les
+ évènements : le thread de travail qui sert la réponse peut envoyer les
+ premiers octets jusqu'Ã ce que <code>EWOULDBLOCK</code> ou
+ <code>EAGAIN</code> soit renvoyé, et déléguer le reste de la réponse au thread
+ d'écoute. Ce dernier en retour attend un évènement sur le socket, et
+ délègue le reste de la réponse au premier
+ thread de travail disponible. Dans la deuxième situation par contre
+ (FCGI/CGI/contenu mandaté), le MPM n'a pas de visibilité sur la fin de
+ la réponse, et le thread de travail doit terminer sa tâche avant de
+ rendre le contrôle au thread d'écoute. La seule solution consisterait
+ alors à stocker la réponse en mémoire, mais ce ne serait pas l'option la
+ plus sure en matière de stabilité du serveur et d'empreinte mémoire.
+ </p>
+
+ </section>
+
+ <section id="background"><title>Matériel d'arrière-plan</title>
+ <p>Le modèle event a été rendu possible par l'introduction de nouvelles
+ APIs dans les systèmes d'exploitation supportés :</p>
+ <ul>
+ <li>epoll (Linux) </li>
+ <li>kqueue (BSD) </li>
+ <li>event ports (Solaris) </li>
+ </ul>
+ <p>Avant que ces APIs soient mises à disposition, les APIs
+ traditionnelles <code>select</code> et <code>poll</code> devaient être
+ utilisées. Ces APIs deviennent lentes si on les utilise pour gérer de
+ nombreuses connexions ou si le jeu de connexions possède un taux de
+ renouvellement élevé. Les nouvelles APIs permettent de gérer beaucoup
+ plus de connexions et leur performances sont meilleures lorsque le jeu
+ de connexions à gérer change fréquemment. Ces APIs ont donc rendu
+ possible l'écriture le MPM Event qui est mieux adapté à la situation
+ HTTP typique où de nombreuses connexions sont inactives.</p>
+
+ <p>Le MPM Event suppose que l'implémentation de <code>apr_pollset</code>
+ sous-jacente est raisonnablement sure avec l'utilisation des threads
+ (threadsafe). Ceci évite au MPM de devoir effectuer trop verrouillages
+ de haut niveau, ou d'avoir à réveiller le thread d'écoute pour lui
+ envoyer un socket keep-alive. Ceci n'est possible qu'avec KQueue et
+ EPoll.</p>
+ </section>
+
</section>
-<section id="requirements"><title>Prérequis</title>
- <p>Ce MPM dépend des opérations atomiques compare-and-swap
+
+<section id="requirements"><title>Prérequis</title>
+ <p>Ce MPM dépend des opérations atomiques compare-and-swap
d'<glossary>APR</glossary> pour la synchronisation des threads. Si
vous compilez pour une plate-forme x86 et n'avez pas besoin du
support 386, ou si vous compilez pour une plate-forme SPARC et
n'avez pas besoin du support pre-UltraSPARC, ajoutez
<code>--enable-nonportable-atomics=yes</code> aux arguments du
- script <program>configure</program>. Ceci permettra à APR
- d'implémenter les opérations atomiques en utilisant des instructions
+ script <program>configure</program>. Ceci permettra à APR
+ d'implémenter les opérations atomiques en utilisant des instructions
performantes indisponibles avec les processeurs plus
anciens.</p>
- <p>Ce MPM ne fonctionne pas de manière optimale sur les
- plates-formes plus anciennes qui ne gèrent pas correctement les
- threads, mais ce problème est sans objet du fait du prérequis
+ <p>Ce MPM ne fonctionne pas de manière optimale sur les
+ plates-formes plus anciennes qui ne gèrent pas correctement les
+ threads, mais ce problème est sans objet du fait du prérequis
concernant EPoll ou KQueue.</p>
<ul>
<li>Pour utiliser ce MPM sous FreeBSD, la version 5.3 ou
- supérieure de ce système est recommandée. Il est cependant
- possible d'exécuter ce MPM sous FreeBSD 5.2.1 si vous utilisez
+ supérieure de ce système est recommandée. Il est cependant
+ possible d'exécuter ce MPM sous FreeBSD 5.2.1 si vous utilisez
<code>libkse</code> (voir <code>man libmap.conf</code>).</li>
<li>Pour NetBSD, il est recommander d'utiliser la version 2.0 ou
- supérieure.</li>
+ supérieure.</li>
- <li>Pour Linux, un noyau 2.6 est recommandé. Il faut aussi
- s'assurer que votre version de <code>glibc</code> a été compilée
+ <li>Pour Linux, un noyau 2.6 est recommandé. Il faut aussi
+ s'assurer que votre version de <code>glibc</code> a été compilée
avec le support pour EPoll.</li>
</ul>
@@ -168,35 +275,39 @@ mobiliser des threads que pour les conne
<directivesynopsis>
<name>AsyncRequestWorkerFactor</name>
-<description>Limite le nombre de connexions simultanées par thread</description>
+<description>Limite le nombre de connexions simultanées par thread</description>
<syntax>AsyncRequestWorkerFactor <var>facteur</var></syntax>
<default>2</default>
<contextlist><context>server config</context> </contextlist>
<compatibility>Disponible depuis la version 2.3.13</compatibility>
<usage>
- <p>Le MPM event gère certaines connexions de manière asynchrone ;
- dans ce cas, les threads traitant la requête sont alloués selon les
- besoins et pour de courtes périodes. Dans les autres cas, un
- thread est réservé par
- connexion. Ceci peut conduire à des situations où tous les threads
- sont saturés et où aucun thread n'est capable d'effectuer de
- nouvelles tâches pour les connexions asynchrones établies.</p>
-
- <p>Pour minimiser les effets de ce problème, le MPM event utilise
- deux méthodes : tout d'abord, il limite le nombre de connexions
- simultanées par thread en fonction du nombre de processus
- inactifs. Ensuite, si tous les processus sont occupés, il ferme des
- connexions permanentes, même si la limite de durée de la connexion
- n'a pas été atteinte. Ceci autorise les clients concernés à se
- reconnecter à un autre processus possèdant encore des threads
- disponibles.</p>
+ <p>Le MPM event gère certaines connexions de manière asynchrone ;
+ dans ce cas, les threads traitant la requête sont alloués selon les
+ besoins et pour de courtes périodes. Dans les autres cas, un
+ thread est réservé par
+ connexion. Ceci peut conduire à des situations où tous les threads
+ sont saturés et où aucun thread n'est capable d'effectuer de
+ nouvelles tâches pour les connexions asynchrones établies.</p>
+
+ <p>Pour minimiser les effets de ce problème, le MPM event utilise
+ deux méthodes :</p>
+ <ul>
+ <li>il limite le nombre de connexions
+ simultanées par thread en fonction du nombre de processus
+ inactifs;</li>
+ <li>si tous les processus sont occupés, il ferme des connexions
+ permanentes, même si la limite de durée de la connexion n'a
+ pas été atteinte. Ceci autorise les clients
+ concernés à se reconnecter à un autre processus
+ possèdant encore des threads disponibles.</li>
+ </ul>
<p>Cette directive permet de personnaliser finement la limite du
- nombre de connexions par thread. Un processus n'acceptera de
+ nombre de connexions par thread. Un <strong>processus</strong> n'acceptera de
nouvelles connexions que si le nombre actuel de connexions (sans
- compter les connexions à l'état "closing") est
- inférieur à :</p>
+ compter les connexions à l'état "closing") est
+ inférieur à :</p>
<p class="indent"><strong>
<directive module="mpm_common">ThreadsPerChild</directive> +
@@ -204,18 +315,82 @@ mobiliser des threads que pour les conne
<var>nombre de threads inactifs</var>)
</strong></p>
- <p>En d'autres termes, le nombre maximum de connexions simultanées
- sera :</p>
+ <p>Il est possible d'effectuer une estimation du nombre maximum de
+ connexions simultanées pour tous les processus et pour un nombre donné moyen
+ de threads de travail inactifs comme suit :
+ </p>
+
+
+ <p class="indent"><strong>
+ (<directive module="mpm_common">ThreadsPerChild</directive> +
+ (<directive>AsyncRequestWorkerFactor</directive> *
+ <var>number of idle workers</var>)) *
+ <directive module="mpm_common">ServerLimit</directive>
+ </strong></p>
+
+ <note><title>Exemple</title>
+ <highlight language="config">
+
+ThreadsPerChild = 10
+ServerLimit = 4
+AsyncRequestWorkerFactor = 2
+MaxRequestWorkers = 40
+
+idle_workers = 4 (moyenne pour tous les processus pour faire simple)
+
+max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) * ServerLimit
+ = (10 + (2 * 4)) * 4 = 72
+
+ </highlight>
+ </note>
+
+ <p>Lorsque tous les threads de travail sont inactifs, le nombre maximum
+ absolu de connexions simultanées peut être calculé de manière plus simple :</p>
<p class="indent"><strong>
(<directive>AsyncRequestWorkerFactor</directive> + 1) *
<directive module="mpm_common">MaxRequestWorkers</directive>
</strong></p>
+ <note><title>Exemple</title>
+ <highlight language="config">
+
+ThreadsPerChild = 10
+ServerLimit = 4
+MaxRequestWorkers = 40
+AsyncRequestWorkerFactor = 2
+
+ </highlight>
+
+ <p>Si tous les threads de tous les processus sont inactifs, alors :</p>
+
+ <highlight language="config">idle_workers = 10</highlight>
+
+ <p>Nous pouvons calculer le nombre maximum absolu de connexions simultanées
+ de deux manières :</p>
+
+ <highlight language="config">
+
+max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) * ServerLimit
+ = (10 + (2 * 10)) * 4 = 120
+
+max_connections = (AsyncRequestWorkerFactor + 1) * MaxRequestWorkers
+ = (2 + 1) * 40 = 120
+
+ </highlight>
+ </note>
+
+ <p>Le réglage de la directive
+ <directive>AsyncRequestWorkerFactor</directive> nécessite de connaître le
+ trafic géré par httpd pour chaque style d'utilisation spécifique ; si vous
+ modifiez la valeur par défaut, vous devrez par conséquent effectuer des
+ tests approfondis en vous appuyant étroitement sur les données fournies par
+ <module>mod_status</module>.</p>
+
<p>La directive <directive
module="mpm_common">MaxRequestWorkers</directive> se nommait
<directive>MaxClients</directive> avant la version 2.3.13. La valeur
- ci-dessus montre que cet ancien nom ne correspondait pas à sa
+ ci-dessus montre que cet ancien nom ne correspondait pas à sa
signification exacte pour le MPM event.</p>
<p>La directive <directive>AsyncRequestWorkerFactor</directive>
Modified: httpd/httpd/branches/2.4.x/docs/manual/sections.xml.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/sections.xml.fr?rev=1732658&r1=1732657&r2=1732658&view=diff
==============================================================================
--- httpd/httpd/branches/2.4.x/docs/manual/sections.xml.fr (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/sections.xml.fr Sat Feb 27 17:48:49 2016
@@ -1,9 +1,9 @@
-<?xml version="1.0" encoding="ISO-8859-1" ?>
+<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision: 1673563:1731194 (outdated) -->
+<!-- English Revision: 1731194 -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
@@ -28,10 +28,10 @@
<summary> <p>Les directives des <a
href="configuring.html">fichiers de configuration</a> 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 <code>.htaccess</code> pour
-modifier la portée des directives de configuration.</p>
+modifier la portée des directives de configuration.</p>
</summary>
<section id="types"><title>Types de conteneurs de sections de
@@ -61,23 +61,23 @@ configuration</title>
</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,
+é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
<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
-directives qu'ils contiennent seront ignorées.</p>
+é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.</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>.
+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>.
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 :
<code>httpd -DClosedForNow</code>:</p>
<highlight language="config">
@@ -89,15 +89,15 @@ un autre site si le serveur est dé
<p>Le conteneur <directive type="section" module="core">IfModule</directive>
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 <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
-indépendamment de la présence ou de l'absence de certains modules.
+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
+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.</p>
+systématiquement, car vous pouvez perdre ainsi de précieux messages d'erreur
+Ã propos de modules manquants.</p>
<p>Dans l'exemple suivant, la directive <directive
module="mod_mime_magic">MimeMagicFile</directive> ne s'appliquera que si le
@@ -114,66 +114,66 @@ module <module>mod_mime_magic</module> e
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
-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.</p>
<highlight language="config">
<IfVersion >= 2.4>
- # les directives situées ici ne s'appliquent que si la version <br />
- # est supérieure ou égale à 2.4.0.
+ # les directives situées ici ne s'appliquent que si la version <br />
+ # est supérieure ou égale à 2.4.0.
</IfVersion>
</highlight>
<p><directive type="section" module="core">IfDefine</directive>,
<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 "!".
-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.</p>
</section>
-<section id="file-and-web"><title>Système de fichiers,
-arborescence du site web et expressions booléennes</title>
+<section id="file-and-web"><title>Système de fichiers,
+arborescence du site web et expressions booléennes</title>
-<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
+<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
+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 à
+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
+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.
+<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>
+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>
+<section id="filesystem"><title>Conteneurs de système de fichiers</title>
<p>Les conteneurs <directive type="section" module="core">Directory</directive>
et <directive type="section" module="core">Files</directive>,
-ainsi que leurs équivalents acceptant les
+ainsi que leurs équivalents acceptant les
<glossary ref="regex">expressions rationnelles</glossary>,
-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 <directive
-type="section" module="core">Directory</directive> s'appliquent au répertoire
-précisé, ainsi qu'à tous ses sous-répertoires et aux fichiers que ces
+type="section" module="core">Directory</directive> 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 <a
+Le même effet peut être obtenu en utilisant les <a
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>
+configuration suivante, l'indexation sera activée pour le répertoire
+<code>/var/web/dir1</code> et tous ses sous-répertoires.</p>
<highlight language="config">
<Directory "/var/web/dir1">
@@ -182,12 +182,12 @@ configuration suivante, l'indexation ser
</highlight>
<p>Les directives contenues dans une section <directive type="section"
-module="core">Files</directive> s'appliquent à tout fichier
-avec le nom spécifié, quel que soit le répertoire dans lequel il se trouve.
+module="core">Files</directive> 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é <code>private.html</code> quel que soit
-l'endroit où il se trouve.</p>
+placées dans la section principale du fichier de configuration, vont interdire
+l'accès à tout fichier nommé <code>private.html</code> quel que soit
+l'endroit où il se trouve.</p>
<highlight language="config">
<Files "private.html">
@@ -195,12 +195,12 @@ l'endroit où il se trouve.</p>
</Files>
</highlight>
-<p>Pour faire référence à des fichiers qui se trouvent en des points
-particuliers du système de fichiers, les sections
+<p>Pour faire référence à des fichiers qui se trouvent en des points
+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
-l'accès à <code>/var/web/dir1/private.html</code>,
+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
<code>private.html</code> qui se trouve dans l'arborescence
@@ -218,16 +218,16 @@ l'accès à <code>/var/web/d
<section id="webspace"><title>Conteneurs de l'arborescence du site web</title>
<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
+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
-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 :
<code>http://yoursite.example.com/private</code>,
<code>http://yoursite.example.com/private123</code>, et
-<code>http://yoursite.example.com/private/dir/file.html</code> ainsi qu'à
-toute requête commençant par la chaîne de caractères <code>/private</code>.</p>
+<code>http://yoursite.example.com/private/dir/file.html</code> ainsi qu'Ã
+toute requête commençant par la chaîne de caractères <code>/private</code>.</p>
<highlight language="config">
<LocationMatch "^/private">
@@ -236,12 +236,12 @@ toute requête commençant pa
</highlight>
<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
+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
<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>
+Il n'est pas nécessaire de trouver un fichier nommé <code>server-status</code>
+dans le système de fichiers.</p>
<highlight language="config">
<Location "/server-status">
@@ -250,9 +250,9 @@ dans le système de fichiers.</p>
</highlight>
</section>
-<section id="overlapping-webspace"><title>Espace web imbriqué</title>
-<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
+<section id="overlapping-webspace"><title>Espace web imbriqué</title>
+<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>
<highlight language="config">
@@ -262,7 +262,7 @@ avoir :</p>
</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"
@@ -276,39 +276,39 @@ ProxyPass "/" "balancer://mycluster/" st
</section>
-<section id="wildcards"><title>Caractères de remplacement
+<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 "/"
+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>
+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
+<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 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>
+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
+répertoires utilisateurs à l'aide de caractères de remplacement
mais sans utiliser
-les expressions rationnelles pourrait ressembler à ceci :</p>
+les expressions rationnelles pourrait ressembler à ceci :</p>
<highlight language="config">
<Directory "/home/*/public_html">
@@ -317,17 +317,17 @@ les expressions rationnelles pourrait re
</highlight>
<p>Avec les conteneurs utilisant les expressions rationnelles,
-on peut interdire l'accès à de nombreux types de fichiers d'images
-simultanément :</p>
+on peut interdire l'accès à de nombreux types de fichiers d'images
+simultanément :</p>
<highlight language="config">
+<FilesMatch "\.(?i:gif|jpe?g|png)$">
Require all denied
</FilesMatch>
</highlight>
-<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
+<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
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>
@@ -340,11 +340,11 @@ href="expr.html">expression</a> et au se
</section>
-<section id="expressions"><title>Expressions booléennes</title>
+<section id="expressions"><title>Expressions booléennes</title>
<p>La directive <directive type="section" module="core">If</directive>
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
+ê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>
<highlight language="config">
<If "!(%{HTTP_REFERER} -strmatch 'http://www.example.com/*')">
@@ -356,21 +356,21 @@ par "http://www.example.com/".</p>
<section id="whichwhen"><title>Que faut-il utiliser et quand ?</title>
-<p>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
+<p>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 <directive type="section"
module="core">Directory</directive> ou <directive type="section"
-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">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
-du système de fichier, ce qui peut permettre de contourner vos restrictions.
+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
+du système de fichier, ce qui peut permettre de contourner vos restrictions.
Par exemple, imaginez la configuration suivante :</p>
<highlight language="config">
@@ -379,66 +379,66 @@ Par exemple, imaginez la configuration s
</Location>
</highlight>
-<p>Elle fonctionne correctement si la requête appelle
+<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
+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
+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
+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>
+<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,
-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
+<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,
+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 <code><Location
-"/"></code> est tout à fait sans rique car ce conteneur va s'appliquer à
-toutes les requêtes sans tenir compte de l'URL spécifique.</p>
+"/"></code> est tout à fait 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
+<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
+module="core">Files</directive> à l'intérieur des sections <directive
type="section" module="core">Directory</directive>, d'autre part, on
peut utiliser les
-directives <directive type="section" module="core">If</directive> à
-l'intérieur des sections <directive type="section"
+directives <directive type="section" module="core">If</directive> Ã
+l'intérieur des sections <directive type="section"
module="core">Directory</directive>, <directive type="section"
module="core">Location</directive> et <directive type="section"
module="core">Files</directive>. Les valeurs des expressions
-rationnelles correspondant aux sections nommées se comportent de manière
+rationnelles correspondant aux sections nommées se comportent de manière
identique.</p>
-<p>Les sections imbriquées sont fusionnées après les sections
-non-imbriquées de même type.</p>
+<p>Les sections imbriquées sont fusionnées après les sections
+non-imbriquées de même type.</p>
</section>
</section>
-<section id="virtualhost"><title>Hôtes virtuels</title>
+<section id="virtualhost"><title>Hôtes virtuels</title>
<p>Le conteneur <directive type="section" module="core">VirtualHost</directive>
-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 <a href="vhosts/">Documentation sur les hôtes virtuels</a>.</p>
+voir la <a href="vhosts/">Documentation sur les hôtes virtuels</a>.</p>
</section>
<section id="proxy"><title>Mandataire</title>
@@ -447,25 +447,25 @@ voir la <a href="vhosts/">Documentation
<directive type="section" module="mod_proxy">Proxy</directive>
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>.
-Par exemple, la configuration suivante
-va interdire l'utilisation du serveur proxy pour accéder au site
-<code>www.example.com</code>.</p>
+sites qui correspondent à l'URL spécifiée et auxquels on a
+accédé via le 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>
<highlight language="config">
<Proxy "http://www.example.com/*">
- Require all granted
+ Require host yournetwork.example.com
</Proxy>
</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
+<p>Pour déterminer quelles sont les directives autorisées pour tel type de
+section de configuration, vérifiez le <a
href="mod/directive-dict.html#Context">Contexte</a> de la directive.
-Tout ce qui est autorisé dans les sections
+Tout ce qui est autorisé dans les sections
<directive type="section" module="core">Directory</directive>
l'est aussi d'un point de vue syntaxique dans les sections
<directive type="section" module="core">DirectoryMatch</directive>,
@@ -488,29 +488,29 @@ module="core">Options</directive> <code>
<directive type="section" module="core">Directory</directive> ou les fichiers
<code>.htaccess</code>.</li>
-<li>La directive <directive module="core">Options</directive> ne peut pas être
-utilisée dans les sections
+<li>La directive <directive module="core">Options</directive> ne peut pas être
+utilisée dans les sections
<directive type="section" module="core">Files</directive>
et <directive type="section" module="core">FilesMatch</directive>.</li>
</ul>
</section>
-<section id="merging"><title>Comment les sections sont combinées entre elles</title>
+<section id="merging"><title>Comment les sections sont combinées entre elles</title>
-<p>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.</p>
+<p>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.</p>
- <p>L'ordre dans lequel les sections sont combinées est :</p>
+ <p>L'ordre dans lequel les sections sont combinées est :</p>
<ol>
<li> Les sections <directive type="section"
- module="core">Directory</directive> (à l'exception des
+ module="core">Directory</directive> (Ã l'exception des
expressions rationnelles)
- et les fichiers <code>.htaccess</code> sont appliqués simultanément (avec
- la possibilité pour <code>.htaccess</code>, s'il y est autorisé, de
- prévaloir sur
+ et les fichiers <code>.htaccess</code> sont appliqués 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
@@ -519,73 +519,140 @@ sont interprétées.</p>
<li>Les sections <directive type="section"
module="core">Files</directive> et <directive
- type="section" module="core">FilesMatch</directive> sont appliquées
- simultanément</li>
+ 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>
+ module="core">LocationMatch</directive> sont appliquées
+ simultanément</li>
<li>Les directives <directive type="section" module="core">If</directive>
</li>
</ol>
- <p>Mises à part les sections <directive type="section"
- module="core">Directory</directive>, chaque groupe est traité selon
- l'ordre dans lequel il apparaît dans les fichiers de configuration.
+ <p>Mises à part les sections <directive type="section"
+ module="core">Directory</directive>, chaque groupe est traité selon
+ l'ordre dans lequel il apparaît dans les fichiers de configuration.
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.
+ sont traitées dans l'ordre du répertoire le plus court vers le plus long.
Par exemple, <code><Directory "/var/web/dir"></code> sera
- traité avant <code><Directory
+ traité avant <code><Directory
"/var/web/dir/subdir"></code>. Si plusieurs sections <directive
- type="section" module="core">Directory</directive> s'appliquent au même
- répertoire, elles sont traitées selon l'ordre dans lequel elles
+ 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.
Les sections de configuration incluses via 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
+ 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
<directive module="core">Include</directive>.</p>
- <p>Les sections situées à l'intérieur de sections <directive type="section"
+ <p>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.</p>
+ 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.</p>
- <p>Quand la requête est servie par le module <module>mod_proxy</module>,
+ <p>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"
type="section">Directory</directive> dans l'ordre de traitement.</p>
+
+ <note><title>Note technique</title>
+ Une séquence <code><Location></code>/<code><LocationMatch></code>
+ est réellement traitée juste avant la phase de traduction du nom
+ (où <code>Aliases</code> et <code>DocumentRoots</code>
+ 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.
+ </note>
+
+<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
+ 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.</p>
+ <p>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.</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
+ 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
+ configuration suivante utilise la directive <directive
+ 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> ?
+ </p>
+ <highlight language="config">
+
+<Directory "/">
+ Header set CustomHeaderName one
+ <FilesMatch ".*">
+ Header set CustomHeaderName three
+ </FilesMatch>
+</Directory>
- <p>Les sections situées plus loin dans le fichier de configuration prévalent
- sur celles qui les précèdent ; cependant, chaque
- module est responsable de la définition de la forme que doit prendre
- cette prévalence. Une section de configuration ultérieure contenant
- des directives d'un certain module peut être à l'origine d'une
- fusion conceptuelle de certaines directives, de toutes les
- directives, ou un remplacement complet de la configuration du module
- par ses valeurs par défaut et les directives explicitement définies
- dans cette section ultérieure.</p>
-
-<note><title>Note technique</title>
- Une séquence
- <code><Location></code>/<code><LocationMatch></code>
- est réellement traitée juste avant la phase de traduction du nom
- (où <code>Aliases</code> et <code>DocumentRoots</code>
- 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.
-</note>
+<Directory "/example">
+ Header set CustomHeaderName two
+</Directory>
+
+ </highlight>
+ <ul>
+ <li><directive>Directory</directive> "/" s'applique, et une configuration
+ initiale est créée qui définit l'en-tête <code>CustomHeaderName</code>
+ avec la valeur <code>one</code>.</li>
+ <li><directive>Directory</directive> "/example" s'applique, et comme
+ <module>mod_headers</module> 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
+ <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>
+ 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
+ basera sur la configuration qui a défini l'en-tête
+ <code>CustomHeaderName</code> Ã la valeur <code>three</code>.
+ <module>mod_headers</module> 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...</li>
+ </ul>
+
+ <p>Ceci est aussi vrai pour les fichiers .htaccess car ils possèdent la même
+ priorité que les sections <directive>Directory</directive> dans l'ordre de
+ fusion. Il faut bien comprendre que les sections de configuration comme
+ <directive>Directory</directive> et <directive>FilesMatch</directive> ne
+ sont pas comparables avec les directives spécifiques de modules comme
+ <directive module="mod_headers">Header</directive> ou <directive
+ module="mod_rewrite">RewriteRule</directive> car elles agissent à des
+ niveaux différents.
+ </p>
+</section>
-<section id="merge-examples"><title>Quelques exemples</title>
+<section id="merge-examples"><title>Quelques exemples utiles</title>
<p>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.</p>
<highlight language="config">
@@ -613,11 +680,11 @@ E.</p>
</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
+de toute 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.
+é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>