From: Lucien Gentis <lgentis@apache.org>
Date: Sat, 27 Feb 2016 17:47:00 +0000 (+0000)
Subject: Rebuild.
X-Git-Tag: 2.5.0-alpha~2000
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=c6f8f7cb21b9ccb0a0aa7a85d9fa6f5c6d4d553a;p=thirdparty%2Fapache%2Fhttpd.git

Rebuild.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1732657 13f79535-47bb-0310-9956-ffa450edef68
---

diff --git a/docs/manual/expr.html.fr b/docs/manual/expr.html.fr
index 5321102848a..a5f59949a1d 100644
--- a/docs/manual/expr.html.fr
+++ b/docs/manual/expr.html.fr
@@ -23,8 +23,7 @@
 <div id="path">
 <a href="http://www.apache.org/">Apache</a> &gt; <a href="http://httpd.apache.org/">Serveur HTTP</a> &gt; <a href="http://httpd.apache.org/docs/">Documentation</a> &gt; <a href="./">Version 2.5</a></div><div id="page-content"><div id="preamble"><h1>Les expressions dans le serveur HTTP Apache</h1>
 <div class="toplang">
-<p><span>Langues Disponibles: </span><a href="./edited/expr.html" hreflang="edited" rel="alternate" title="">&nbsp;edited&nbsp;</a> |
-<a href="./en/expr.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |
+<p><span>Langues Disponibles: </span><a href="./en/expr.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |
 <a href="./fr/expr.html" title="Français">&nbsp;fr&nbsp;</a></p>
 </div>
 
@@ -652,8 +651,7 @@ Header always set CustomHeader my-value "expr=%{REQUEST_URI} =~ m#^/special_path
     de la version 2.5.0 du serveur HTTP Apache.</p>
 </div></div>
 <div class="bottomlang">
-<p><span>Langues Disponibles: </span><a href="./edited/expr.html" hreflang="edited" rel="alternate" title="">&nbsp;edited&nbsp;</a> |
-<a href="./en/expr.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |
+<p><span>Langues Disponibles: </span><a href="./en/expr.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |
 <a href="./fr/expr.html" title="Français">&nbsp;fr&nbsp;</a></p>
 </div><div class="top"><a href="#page-header"><img src="./images/up.gif" alt="top" /></a></div><div class="section"><h2><a id="comments_section" name="comments_section">Commentaires</a></h2><div class="warning"><strong>Notice:</strong><br />This is not a Q&amp;A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our <a href="http://httpd.apache.org/lists.html">mailing lists</a>.</div>
 <script type="text/javascript"><!--//--><![CDATA[//><!--
diff --git a/docs/manual/expr.xml.meta b/docs/manual/expr.xml.meta
index baaa5f7830c..d5a2e5e1a51 100644
--- a/docs/manual/expr.xml.meta
+++ b/docs/manual/expr.xml.meta
@@ -7,7 +7,6 @@
   <relpath>.</relpath>
 
   <variants>
-    <variant>edited</variant>
     <variant>en</variant>
     <variant>fr</variant>
   </variants>
diff --git a/docs/manual/mod/event.html.fr b/docs/manual/mod/event.html.fr
index 043252d4d85..505153d166a 100644
--- a/docs/manual/mod/event.html.fr
+++ b/docs/manual/mod/event.html.fr
@@ -29,8 +29,6 @@
 <p><span>Langues Disponibles: </span><a href="../en/mod/event.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |
 <a href="../fr/mod/event.html" title="Français">&nbsp;fr&nbsp;</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>
@@ -38,15 +36,12 @@ mobiliser des threads que pour les connexions en cours de traitement</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
@@ -56,6 +51,7 @@ mobiliser des threads que pour les connexions en cours de traitement</td></tr>
 </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>
@@ -87,48 +83,159 @@ mobiliser des threads que pour les connexions en cours de traitement</td></tr>
 </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>
@@ -184,16 +291,20 @@ mobiliser des threads que pour les connexions en cours de traitement</td></tr>
     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>
@@ -204,14 +315,70 @@ mobiliser des threads que pour les connexions en cours de traitement</td></tr>
         <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
diff --git a/docs/manual/mod/event.xml.meta b/docs/manual/mod/event.xml.meta
index 58ce5cc0734..7b7fc287cfe 100644
--- a/docs/manual/mod/event.xml.meta
+++ b/docs/manual/mod/event.xml.meta
@@ -8,6 +8,6 @@
 
   <variants>
     <variant>en</variant>
-    <variant outdated="yes">fr</variant>
+    <variant>fr</variant>
   </variants>
 </metafile>
diff --git a/docs/manual/mod/mod_speling.xml.ja b/docs/manual/mod/mod_speling.xml.ja
index 0ab31a3c85f..f62b9a13874 100644
--- a/docs/manual/mod/mod_speling.xml.ja
+++ b/docs/manual/mod/mod_speling.xml.ja
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="UTF-8" ?>
 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
-<!-- English Revision: 420990:1557580 (outdated) -->
+<!-- English Revision: 420990:1732273 (outdated) -->
 
 <!--
  Licensed to the Apache Software Foundation (ASF) under one or more
diff --git a/docs/manual/mod/mod_speling.xml.ko b/docs/manual/mod/mod_speling.xml.ko
index e89efc070d4..6f8371b1e4e 100644
--- a/docs/manual/mod/mod_speling.xml.ko
+++ b/docs/manual/mod/mod_speling.xml.ko
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="EUC-KR" ?>
 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
-<!-- English Revision: 395228:1557580 (outdated) -->
+<!-- English Revision: 395228:1732273 (outdated) -->
 
 <!--
  Licensed to the Apache Software Foundation (ASF) under one or more
diff --git a/docs/manual/sections.html.fr b/docs/manual/sections.html.fr
index 0581d8537b7..06054c8b215 100644
--- a/docs/manual/sections.html.fr
+++ b/docs/manual/sections.html.fr
@@ -29,8 +29,6 @@
 <a href="./ko/sections.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a> |
 <a href="./tr/sections.html" hreflang="tr" rel="alternate" title="Türkçe">&nbsp;tr&nbsp;</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
@@ -402,12 +400,12 @@ et <code class="directive"><a href="./mod/mod_proxy.html#proxymatch">&lt;ProxyMa
 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">&lt;Proxy http://www.example.com/*&gt;
-    Require all granted
+    Require host yournetwork.example.com
 &lt;/Proxy&gt;</pre>
 
 </div><div class="top"><a href="#page-header"><img alt="top" src="./images/up.gif" /></a></div>
@@ -500,28 +498,90 @@ sont interpr
     <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">&lt;Proxy&gt;</a></code>
     prend la place du conteneur <code class="directive"><a href="./mod/core.html#directory">&lt;Directory&gt;</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>&lt;Location&gt;</code>/<code>&lt;LocationMatch&gt;</code>
+    
+	<div class="note"><h3>Note technique</h3>
+	Une séquence <code>&lt;Location&gt;</code>/<code>&lt;LocationMatch&gt;</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">&lt;Directory "/"&gt;
+    Header set CustomHeaderName one
+    &lt;FilesMatch ".*"&gt;
+        Header set CustomHeaderName three
+    &lt;/FilesMatch&gt;
+&lt;/Directory&gt;
 
-<h3><a name="merge-examples" id="merge-examples">Quelques exemples</a></h3>
+&lt;Directory "/example"&gt;
+    Header set CustomHeaderName two
+&lt;/Directory&gt;</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
diff --git a/docs/manual/sections.xml.meta b/docs/manual/sections.xml.meta
index 0e839c6dc7f..f5ac84359d4 100644
--- a/docs/manual/sections.xml.meta
+++ b/docs/manual/sections.xml.meta
@@ -8,7 +8,7 @@
 
   <variants>
     <variant>en</variant>
-    <variant outdated="yes">fr</variant>
+    <variant>fr</variant>
     <variant outdated="yes">ja</variant>
     <variant outdated="yes">ko</variant>
     <variant outdated="yes">tr</variant>