<p><span>Langues Disponibles: </span><a href="../en/mod/event.html" hreflang="en" rel="alternate" title="English"> en </a> |
<a href="../fr/mod/event.html" title="Français"> fr </a></p>
</div>
-<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
- anglaise pour les changements récents.</div>
<table class="module"><tr><th><a href="module-dict.html#Description">Description:</a></th><td>Une variante du MPM <code class="module"><a href="../mod/worker.html">worker</a></code> conçue pour ne
mobiliser des threads que pour les connexions en cours de traitement</td></tr>
<tr><th><a href="module-dict.html#Status">Statut:</a></th><td>MPM</td></tr>
<tr><th><a href="module-dict.html#SourceFile">Fichier Source:</a></th><td>event.c</td></tr></table>
<h3>Sommaire</h3>
- <p>Le module multi-processus (MPM) <code class="module"><a href="../mod/event.html">event</a></code> est conçu
+ <p>Le module multi-processus (MPM) <code class="module"><a href="../mod/event.html">event</a></code> est, comme son nom
+ l'indique, une implémentation asynchrone basée sur les évènements et 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
- <code class="module"><a href="../mod/worker.html">worker</a></code> qui implémente un serveur hybride
- multi-processus/multi-threads. Les directives de configuration à
- l'exécution sont identiques à celles du MPM
- <code class="module"><a href="../mod/worker.html">worker</a></code>.</p>
+ 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 <code class="module"><a href="../mod/event.html">event</a></code>, ajoutez
<code>--with-mpm=event</code> aux arguments du script
</div>
<div id="quickview"><h3>Sujets</h3>
<ul id="topics">
+<li><img alt="" src="../images/down.gif" /> <a href="#event-worker-relationship">Relations avec le MPM Worker</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#how-it-works">Comment tout cela fonctionne</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#requirements">Prérequis</a></li>
</ul><h3 class="directives">Directives</h3>
</ul><ul class="seealso"><li><a href="#comments_section">Commentaires</a></li></ul></div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
+<h2><a name="event-worker-relationship" id="event-worker-relationship">Relations avec le MPM Worker</a></h2>
+<p>Le MPM <code class="module"><a href="../mod/event.html">event</a></code> s'inspire du MPM <code class="module"><a href="../mod/worker.html">worker</a></code> 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
+<code class="directive"><a href="../mod/mpm_common.html#threadsperchild">ThreadsPerChild</a></code>, 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 <code class="module"><a href="../mod/worker.html">worker</a></code>, avec l'unique addition de la directive
+<code class="directive">AsyncRequestWorkerFactor</code>.</p>
+
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
<h2><a name="how-it-works" id="how-it-works">Comment tout cela fonctionne</a></h2>
- <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, <code class="module"><a href="../mod/event.html">event</a></code>
- 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
- <code class="module"><a href="../mod/mod_status.html">mod_status</a></code> 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 <code class="module"><a href="../mod/worker.html">worker</a></code> 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 a été conçu à l'origine pour 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 associé à un jeu de
+ threads de travail, partageant les files d'attentes spécifiques aux
+ requêtes en mode keep-alive (ou plus simplement en mode "lisible"), à celles
+ en mode écriture des résultats, et à celles en court de fermeture
+ ("closing"). Une boucle d'attente d'évènements déclenchée en fonction du
+ statut de la disponibilité du socket ajuste ces files d'attente et distribue
+ le travail au jeu de threads de travail.
+ </p>
+
+ <p>La directive <code class="directive">AsyncRequestWorkerFactor</code> permet de
+ définir le nombre total de connexions qu'un bloc processus/thread peut
+ gérer.</p>
+
+ <h3><a name="async-connections" id="async-connections">Connexions asynchrones</a></h3>
+ <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 <code class="module"><a href="../mod/mod_status.html">mod_status</a></code> 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 <code class="directive"><a href="../mod/core.html#keepalivetimeout">KeepAliveTimeout</a></code> 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>
+
+
+ <h3><a name="limitations" id="limitations">Limitations</a></h3>
+ <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 <code class="module"><a href="../mod/worker.html">worker</a></code> 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>
+
+
+
+ <h3><a name="background" id="background">Matériel d'arrière-plan</a></h3>
+ <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>
+
+
+
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="requirements" id="requirements">Prérequis</a></h2>
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>
+ 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>
<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>
+ (<code class="directive"><a href="../mod/mpm_common.html#threadsperchild">ThreadsPerChild</a></code> +
+ (<code class="directive">AsyncRequestWorkerFactor</code> *
+ <var>number of idle workers</var>)) *
+ <code class="directive"><a href="../mod/mpm_common.html#serverlimit">ServerLimit</a></code>
+ </strong></p>
+
+ <div class="note"><h3>Exemple</h3>
+ <pre class="prettyprint lang-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</pre>
+
+ </div>
+
+ <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>
(<code class="directive">AsyncRequestWorkerFactor</code> + 1) *
<code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code>
</strong></p>
+ <div class="note"><h3>Exemple</h3>
+ <pre class="prettyprint lang-config">ThreadsPerChild = 10
+ServerLimit = 4
+MaxRequestWorkers = 40
+AsyncRequestWorkerFactor = 2</pre>
+
+
+ <p>Si tous les threads de tous les processus sont inactifs, alors :</p>
+
+ <pre class="prettyprint lang-config">idle_workers = 10</pre>
+
+
+ <p>Nous pouvons calculer le nombre maximum absolu de connexions simultanées
+ de deux manières :</p>
+
+ <pre class="prettyprint lang-config">max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) * ServerLimit
+ = (10 + (2 * 10)) * 4 = 120
+
+max_connections = (AsyncRequestWorkerFactor + 1) * MaxRequestWorkers
+ = (2 + 1) * 40 = 120</pre>
+
+ </div>
+
+ <p>Le réglage de la directive
+ <code class="directive">AsyncRequestWorkerFactor</code> 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
+ <code class="module"><a href="../mod/mod_status.html">mod_status</a></code>.</p>
+
<p>La directive <code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code> se nommait
<code class="directive">MaxClients</code> avant la version 2.3.13. La valeur
ci-dessus montre que cet ancien nom ne correspondait pas à sa
<a href="./ko/sections.html" hreflang="ko" rel="alternate" title="Korean"> ko </a> |
<a href="./tr/sections.html" hreflang="tr" rel="alternate" title="Türkçe"> tr </a></p>
</div>
-<div class="outofdate">Cette traduction peut être périmée. Vérifiez la version
- anglaise pour les changements récents.</div>
<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
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 <code class="module"><a href="./mod/mod_proxy.html">mod_proxy</a></code>.
-Par exemple, la configuration suivante
-va interdire l'utilisation du serveur proxy pour accéder au site
-<code>www.example.com</code>.</p>
+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>
<pre class="prettyprint lang-config"><Proxy http://www.example.com/*>
- Require all granted
+ Require host yournetwork.example.com
</Proxy></pre>
</div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
<p>Quand la requête est servie par le module <code class="module"><a href="./mod/mod_proxy.html">mod_proxy</a></code>,
le conteneur <code class="directive"><a href="./mod/mod_proxy.html#proxy"><Proxy></a></code>
prend la place du conteneur <code class="directive"><a href="./mod/core.html#directory"><Directory></a></code> dans l'ordre de traitement.</p>
-
- <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>
-
-<div class="note"><h3>Note technique</h3>
- Une séquence
- <code><Location></code>/<code><LocationMatch></code>
+
+ <div class="note"><h3>Note technique</h3>
+ 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.
-</div>
+ </div>
+
+<h3><a name="relationship-module-configuration" id="relationship-module-configuration">Interactions entre
+modules et sections de configuration</a></h3>
+ <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 <code class="module"><a href="./mod/mod_rewrite.html">mod_rewrite</a></code> 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 <code class="directive"><a href="./mod/mod_headers.html#header">Header</a></code> du module
+ <code class="module"><a href="./mod/mod_headers.html">mod_headers</a></code> 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>
+ <pre class="prettyprint lang-config"><Directory "/">
+ Header set CustomHeaderName one
+ <FilesMatch ".*">
+ Header set CustomHeaderName three
+ </FilesMatch>
+</Directory>
-<h3><a name="merge-examples" id="merge-examples">Quelques exemples</a></h3>
+<Directory "/example">
+ Header set CustomHeaderName two
+</Directory></pre>
+
+ <ul>
+ <li><code class="directive">Directory</code> "/" 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><code class="directive">Directory</code> "/example" s'applique, et comme
+ <code class="module"><a href="./mod/mod_headers.html">mod_headers</a></code> 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><code class="directive">FilesMatch</code> ".*" 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, <code class="module"><a href="./mod/mod_headers.html">mod_headers</a></code> 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>.
+ <code class="module"><a href="./mod/mod_headers.html">mod_headers</a></code> 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 <code class="directive">Directory</code> dans l'ordre de
+ fusion. Il faut bien comprendre que les sections de configuration comme
+ <code class="directive">Directory</code> et <code class="directive">FilesMatch</code> ne
+ sont pas comparables avec les directives spécifiques de modules comme
+ <code class="directive"><a href="./mod/mod_headers.html#header">Header</a></code> ou <code class="directive"><a href="./mod/mod_rewrite.html#rewriterule">RewriteRule</a></code> car elles agissent à des
+ niveaux différents.
+ </p>
+
+
+<h3><a name="merge-examples" id="merge-examples">Quelques exemples utiles</a></h3>
<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
projects / thirdparty / apache / httpd.git / commitdiff
