httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lgen...@apache.org
Subject svn commit: r1732658 - in /httpd/httpd/branches/2.4.x/docs/manual: mod/event.xml.fr sections.xml.fr
Date Sat, 27 Feb 2016 17:48:49 GMT
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&ccedil;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&ccedil;u
-    pour permettre le traitement d'un nombre accru de requ&ecirc;tes
-    simultan&eacute;es en d&eacute;l&eacute;guant certaines t&acirc;ches &agrave; des threads de support,
-    lib&eacute;rant par l&agrave;-m&ecirc;me le thread principal et lui permettant de
-    traiter les nouvelles requ&ecirc;tes. Il s'inspire du MPM
-    <module>worker</module> qui impl&eacute;mente un serveur hybride
-    multi-processus/multi-threads. Les directives de configuration &agrave;
-    l'ex&eacute;cution sont identiques &agrave; 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&eacute;soudre le 'probl&egrave;me keep alive' de HTTP.
-    Lorsqu'un client a soumis une premi&egrave;re requ&ecirc;te, il peut garder la
-    connexion ouverte, et envoyer les requ&ecirc;tes suivantes en utilisant le
-    m&ecirc;me socket. Ceci permet de r&eacute;duire de mani&egrave;re significative la
-    surcharge due &agrave; la cr&eacute;ation de connexions TCP.
-    Cependant, le serveur HTTP Apache
-    mobilise en principe &agrave; cet effet un processus/thread enfant en
-    attente des donn&eacute;es du client, ce qui am&egrave;ne son propre lot
-    d'inconv&eacute;nients. Pour r&eacute;soudre ce probl&egrave;me, <module>event</module>
-    utilise un thread d&eacute;di&eacute; qui g&egrave;re les sockets en
-    &eacute;coute, tous les sockets en &eacute;tat Keep Alive, et les
-    sockets o&ugrave; les filtres gestionnaires et de protocole ont
-    fait leur travail et pour lesquels la seule chose restant &agrave; faire
-    consiste &agrave; envoyer les donn&eacute;es au client. La page d'&eacute;tat de
-    <module>mod_status</module> montre les connexions qui se trouvent
-    dans les situations mentionn&eacute;es.</p>
-
-    <p>Le gestionnaire de connexion am&eacute;lior&eacute; peut ne pas
-    fonctionner pour les filtres de connexion qui se d&eacute;clarent eux-m&ecirc;mes
-    comme incompatibles avec le MPM event. Dans ce cas, le MPM event
-    adopte le comportement du MPM <module>worker</module> et
-    r&eacute;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&ecirc;tes qui utilisent
-    un filtre en sortie qui doit lire et/ou modifier l'ensemble du corps
-    de r&eacute;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&eacute;es, et si la quantit&eacute; de donn&eacute;es g&eacute;n&eacute;r&eacute;e par
-    ce filtre est trop importante pour &ecirc;tre mise en tampon m&eacute;moire, le
-    thread utilis&eacute; pour la requ&ecirc;te n'est pas lib&eacute;r&eacute; pendant que httpd
-    attend que toutes les donn&eacute;es restantes aient &eacute;t&eacute; transmises au
-    client.</p>
-
-    <p>Le MPM pr&eacute;suppose que l'impl&eacute;mentation <code>apr_pollset</code>
-    sous-jacente est raisonnablement s&ucirc;re du point de vue des threads.
-    Ceci permet au MPM d'&eacute;viter un verrouillage de haut niveau excessif,
-    ou de devoir activer le thread en &eacute;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&eacute;requis</title>
-    <p>Ce MPM d&eacute;pend des op&eacute;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 &agrave; APR
-    d'impl&eacute;menter les op&eacute;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&egrave;re optimale sur les
-    plates-formes plus anciennes qui ne g&egrave;rent pas correctement les
-    threads, mais ce probl&egrave;me est sans objet du fait du pr&eacute;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&eacute;rieure de ce syst&egrave;me est recommand&eacute;e. Il est cependant
-      possible d'ex&eacute;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&eacute;rieure.</li>
+      supérieure.</li>
 
-      <li>Pour Linux, un noyau 2.6 est recommand&eacute;. Il faut aussi
-      s'assurer que votre version de <code>glibc</code> a &eacute;t&eacute; compil&eacute;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&eacute;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&egrave;re certaines connexions de mani&egrave;re asynchrone ;
-    dans ce cas, les threads traitant la requ&ecirc;te sont allou&eacute;s selon les
-    besoins et pour de courtes p&eacute;riodes. Dans les autres cas, un
-    thread est r&eacute;serv&eacute; par
-    connexion. Ceci peut conduire &agrave; des situations o&ugrave; tous les threads
-    sont satur&eacute;s et o&ugrave; aucun thread n'est capable d'effectuer de
-    nouvelles t&acirc;ches pour les connexions asynchrones &eacute;tablies.</p>
-
-    <p>Pour minimiser les effets de ce probl&egrave;me, le MPM event utilise
-    deux m&eacute;thodes : tout d'abord, il limite le nombre de connexions
-    simultan&eacute;es par thread en fonction du nombre de processus
-    inactifs. Ensuite, si tous les processus sont occup&eacute;s, il ferme des
-    connexions permanentes, m&ecirc;me si la limite de dur&eacute;e de la connexion
-    n'a pas &eacute;t&eacute; atteinte. Ceci autorise les clients concern&eacute;s &agrave; se
-    reconnecter &agrave; un autre processus poss&egrave;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'&eacute;tat "closing") est
-    inf&eacute;rieur &agrave; :</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&eacute;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 &agrave; 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 &agrave; des r&eacute;pertoires, fichiers, h&ocirc;tes,
-ou URLs particuliers.  Ce document d&eacute;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&eacute;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
-&eacute;valu&eacute;s pour chaque requ&ecirc;te.  Les directives qu'ils contiennent s'appliquent
-seulement aux requ&ecirc;tes qui sont concern&eacute;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
-&eacute;valu&eacute;s seulement au d&eacute;marrage et au red&eacute;marrage du serveur.
-Si leurs conditions sont v&eacute;rifi&eacute;es au d&eacute;marrage, les directives qu'ils contiennent
-s'appliqueront &agrave; toutes les requ&ecirc;tes.  Si leurs conditions ne sont pas v&eacute;rifi&eacute;es, les
-directives qu'ils contiennent seront ignor&eacute;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&eacute;es que si un param&egrave;tre
-appropri&eacute; a &eacute;t&eacute; d&eacute;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&ecirc;tes seront redirig&eacute;es vers
-un autre site si le serveur est d&eacute;marr&eacute; 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&eacute
 <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 &ecirc;tre soit compil&eacute; 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&icirc;tre
-plus haut dans le fichier de configuration.  Ce conteneur ne doit &ecirc;tre
-utilis&eacute; que dans le cas o&ugrave; votre fichier de configuration doit fonctionner
-ind&eacute;pendamment de la pr&eacute;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&eacute;matiquement, car vous pouvez perdre ainsi de pr&eacute;cieux messages d'erreur
-&agrave; 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&egrave;re du serveur s'ex&eacute;cute.  Ce
-conteneur a &eacute;t&eacute; con&ccedil;u pour une utilisation dans les suites de tests
-et les grands r&eacute;seaux qui doivent prendre en compte diff&eacute;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">
 &lt;IfVersion >= 2.4&gt;
-    # les directives situ&eacute;es ici ne s'appliquent que si la version <br />
-    # est sup&eacute;rieure ou &eacute;gale &agrave; 2.4.0.
+    # les directives situées ici ne s'appliquent que si la version <br />
+    # est supérieure ou égale à 2.4.0.
 &lt;/IfVersion&gt;
 </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&eacute;c&eacute;der d'un "!".
-De plus, ces sections peuvent &ecirc;tre imbriqu&eacute;es afin de d&eacute;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&egrave;me de fichiers,
-arborescence du site web et expressions bool&eacute;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&eacute;s
-sont ceux qui modifient la configuration de points particuliers du syst&egrave;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&eacute;rence entre les deux.  Le syst&egrave;me de fichiers est une vue
-de vos disques tels qu'ils sont per&ccedil;us par votre syst&egrave;me d'exploitation.
-Par exemple, avec une installation par d&eacute;faut,
-Apache httpd est situ&eacute; dans <code>/usr/local/apache2</code> pour le syst&egrave;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&egrave;me de fichiers Windows.  (Notez que des slashes directs doivent
-toujours &ecirc;tre utilis&eacute;s comme s&eacute;parateur de chemin
-dans les fichiers de configuration d'Apache httpd, m&ecirc;me sous
-Windows.)  Quant &agrave;
+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&eacute;sent&eacute; par le
-serveur web et per&ccedil;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&egrave;me de fichiers pour
-une installation d'Apache httpd par d&eacute;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&egrave;me de fichiers, car les pages web peuvent &ecirc;tre g&eacute;n&eacute;r&eacute;es dynamiquement
-&agrave; partir de bases de donn&eacute;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&egrave;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 &eacute;quivalents acceptant les
+ainsi que leurs équivalents acceptant les
 <glossary ref="regex">expressions rationnelles</glossary>,
-appliquent des directives &agrave; certaines parties du syst&egrave;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&eacute;pertoire
-pr&eacute;cis&eacute;, ainsi qu'&agrave; tous ses sous-r&eacute;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&ecirc;me effet peut &ecirc;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&eacute;e pour le r&eacute;pertoire
-<code>/var/web/dir1</code> et tous ses sous-r&eacute;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">
 &lt;Directory "/var/web/dir1"&gt;
@@ -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 &agrave; tout fichier
-avec le nom sp&eacute;cifi&eacute;, quel que soit le r&eacute;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&eacute;es dans la section principale du fichier de configuration, vont interdire
-l'acc&egrave;s &agrave; tout fichier nomm&eacute; <code>private.html</code> quel que soit
-l'endroit o&ugrave; 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">
 &lt;Files "private.html"&gt;
@@ -195,12 +195,12 @@ l'endroit o&ugrave; il se trouve.</p>
 &lt;/Files&gt;
 </highlight>
 
-<p>Pour faire r&eacute;f&eacute;rence &agrave; des fichiers qui se trouvent en des points
-particuliers du syst&egrave;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 &ecirc;tre combin&eacute;es.  Par exemple, la configuration suivante va interdire
-l'acc&egrave;s &agrave; <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&egrave;s &agrave; <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 &eacute;quivalent acceptant les
-<glossary ref="regex">expressions rationnelles</glossary>, modifient quant &agrave; 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&egrave;s &agrave; 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&ecirc;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'&agrave;
-toute requ&ecirc;te commen&ccedil;ant par la cha&icirc;ne de caract&egrave;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">
 &lt;LocationMatch "^/private"&gt;
@@ -236,12 +236,12 @@ toute requ&ecirc;te commen&ccedil;ant pa
 </highlight>
 
 <p>Le conteneur <directive type="section" module="core">Location</directive>
-n'a pas besoin de faire r&eacute;f&eacute;rence &agrave; un &eacute;l&eacute;ment du syst&egrave;me de fichiers.
-Par exemple, l'exemple suivant montre comment faire r&eacute;f&eacute;rence &agrave; une URL
-particuli&egrave;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&eacute;cessaire de trouver un fichier nomm&eacute; <code>server-status</code>
-dans le syst&egrave;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">
 &lt;Location "/server-status"&gt;
@@ -250,9 +250,9 @@ dans le syst&egrave;me de fichiers.</p>
 </highlight>
 </section>
 
-<section id="overlapping-webspace"><title>Espace web imbriqu&eacute;</title>
-<p>Pour contr&ocirc;ler deux URLs imbriqu&eacute;es, on doit tenir compte de l'ordre
-dans lequel certaines sections ou directives sont &eacute;valu&eacute;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>
 &lt;/Location>
 </highlight>
 <p>Les directives <directive type="section"
-module="mod_alias">Alias</directive>, quant &agrave; elles, sont &eacute;valu&eacute;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&egrave;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&egrave;res de remplacement de style shell comme dans
-la fonction <code>fnmatch</code> de la biblioth&egrave;que C standard.
-Le caract&egrave;re "*"
-correspond &agrave; toute s&eacute;quence de caract&egrave;res, "?" &agrave; un caract&egrave;re seul,
-et "[<em>seq</em>]" &agrave; tout caract&egrave;re contenu dans <em>seq</em>.
-Le caract&egrave;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 &ecirc;tre sp&eacute;cifi&eacute; explicitement.</p>
+il doit être spécifié explicitement.</p>
 
-<p>Si une d&eacute;finition des crit&egrave;res de correspondance
-encore plus souple est n&eacute;cessaire, chaque conteneur
-poss&egrave;de son &eacute;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&eacute;finir les crit&egrave;res de correspondance.  Mais voyez plus loin la section
-&agrave; 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&egrave;re
-dont les directives sont appliqu&eacute;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&eacute;pertoires utilisateurs &agrave; l'aide de caract&egrave;res de remplacement
+répertoires utilisateurs à l'aide de caractères de remplacement
 mais sans utiliser
-les expressions rationnelles pourrait ressembler &agrave; ceci :</p>
+les expressions rationnelles pourrait ressembler à ceci :</p>
 
 <highlight language="config">
 &lt;Directory "/home/*/public_html"&gt;
@@ -317,17 +317,17 @@ les expressions rationnelles pourrait re
 </highlight>
 
 <p>Avec les conteneurs utilisant les expressions rationnelles,
-on peut interdire l'acc&egrave;s &agrave; de nombreux types de fichiers d'images
-simultan&eacute;ment :</p>
+on peut interdire l'accès à de nombreux types de fichiers d'images
+simultanément :</p>
 <highlight language="config">
 +&lt;FilesMatch "\.(?i:gif|jpe?g|png)$"&gt;
     Require all denied
 &lt;/FilesMatch&gt;
 </highlight>
 
-<p>Les expressions rationnelles contenant des <strong>groupes nomm&eacute;s et
-des r&eacute;f&eacute;rences arri&egrave;res</strong> sont ajout&eacute;es &agrave; l'environnement avec
-leur nom en majuscules. Ceci permet de r&eacute;f&eacute;rencer des &eacute;l&eacute;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&eacute;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
-&ecirc;tre d&eacute;finie sous la forme d'une expression bool&eacute;enne. Dans l'exemple
-suivant, l'acc&egrave;s est interdit si l'en-t&ecirc;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">
 &lt;If "!(%{HTTP_REFERER} -strmatch 'http://www.example.com/*')"&gt;
@@ -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&egrave;me de fichiers et des conteneurs
-d'arborescence du site web est vraiment tr&egrave;s simple.
-Pour appliquer des directives &agrave; des objets qui r&eacute;sident dans le syst&egrave;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 &agrave; des objets
-qui ne r&eacute;sident pas dans le syst&egrave;me de fichiers (comme une page web g&eacute;n&eacute;r&eacute;e
-par une base de donn&eacute;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&egrave;s &agrave; des
-objets du syst&egrave;me de fichiers, car plusieurs localisations de
-l'arborescence du site web (URLs) peuvent correspondre &agrave; la m&ecirc;me localisation
-du syst&egrave;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
 &lt;/Location&gt;
 </highlight>
 
-<p>Elle fonctionne correctement si la requ&ecirc;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&egrave;me de fichiers est insensible &agrave; la casse ?
-Votre restriction va pouvoir &ecirc;tre tout simplement contourn&eacute;e en envoyant une
-requ&ecirc;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 &agrave; lui, s'appliquera
-&agrave; tout contenu servi &agrave; partir de cette localisation,
-sans tenir compte de la mani&egrave;re dont il est appel&eacute;.
-(Les liens du syst&egrave;me de fichiers constituent une exception.
-Le m&ecirc;me r&eacute;pertoire peut &ecirc;tre plac&eacute; dans plusieurs parties du syst&egrave;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&eacute;quent, pour plus de
-s&eacute;curit&eacute;, les liens symboliques doivent &ecirc;tre d&eacute;sactiv&eacute;s &agrave; 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&eacute;e.)</p>
+<directive module="core">Options</directive> appropriée.)</p>
 
-<p>Si vous pensez que vous n'&ecirc;tes pas concern&eacute; par ce probl&egrave;me
-parceque vous utilisez un syst&egrave;me de fichiers sensible &agrave; la casse,
-gardez &agrave; l'esprit qu'il y a de nombreuses autres mani&egrave;res pour faire
-correspondre plusieurs localisations de l'arborescence du site web &agrave; la m&ecirc;me
-localisation du syst&egrave;me de fichiers.  C'est pourquoi vous devez autant que
-possible toujours utiliser les conteneurs de syst&egrave;me de fichiers.
-Il y a cependant une exception &agrave; cette r&egrave;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>&lt;Location
-"/"&gt;</code> est tout &agrave; fait sans rique car ce conteneur va s'appliquer &agrave;
-toutes les requ&ecirc;tes sans tenir compte de l'URL sp&eacute;cifique.</p>
+"/"&gt;</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 &ecirc;tre imbriqu&eacute;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> &agrave; l'int&eacute;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> &agrave;
-l'int&eacute;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&eacute;es se comportent de mani&egrave;re
+rationnelles correspondant aux sections nommées se comportent de manière
 identique.</p>
 
-<p>Les sections imbriqu&eacute;es sont fusionn&eacute;es apr&egrave;s les sections
-non-imbriqu&eacute;es de m&ecirc;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&ocirc;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 &agrave; des h&ocirc;tes sp&eacute;cifiques.
-Ceci s'av&egrave;re utile pour servir des h&ocirc;tes multiples &agrave; partir de la m&ecirc;me machine,
-chacun d'entre eux poss&eacute;dant une configuration diff&eacute;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&ocirc;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 &agrave; l'URL sp&eacute;cifi&eacute;e et auxquels on a
-acc&eacute;d&eacute; via le serveur mandataire du module <module>mod_proxy</module>.
-Par exemple, la configuration suivante
-va interdire l'utilisation du serveur proxy pour acc&eacute;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">
 &lt;Proxy "http://www.example.com/*"&gt;
-    Require all granted
+    Require host yournetwork.example.com
 &lt;/Proxy&gt;
 </highlight>
 </section>
 
-<section id="whatwhere"><title>Quelles sont les directives autoris&eacute;es ?</title>
+<section id="whatwhere"><title>Quelles sont les directives autorisées ?</title>
 
-<p>Pour d&eacute;terminer quelles sont les directives autoris&eacute;es pour tel type de
-section de configuration, v&eacute;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&eacute; 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 &ecirc;tre
-utilis&eacute;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&eacute;es entre elles</title>
+<section id="merging"><title>Comment les sections sont combinées entre elles</title>
 
-<p>Les sections de configuration sont appliqu&eacute;es dans un ordre tr&egrave;s particulier.
-Il est important de savoir comment cet ordre est d&eacute;fini car il peut avoir
-des effets importants sur la mani&egrave;re dont les directives de configuration
-sont interpr&eacute;t&eacute;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&eacute;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> (&agrave; l'exception des
+      module="core">Directory</directive> (à l'exception des
       expressions rationnelles)
-      et les fichiers <code>.htaccess</code> sont appliqu&eacute;s simultan&eacute;ment (avec
-      la possibilit&eacute; pour <code>.htaccess</code>, s'il y est autoris&eacute;, de
-      pr&eacute;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&eacute;t&eacute;es.</p>
 
       <li>Les sections <directive type="section"
       module="core">Files</directive> et <directive
-      type="section" module="core">FilesMatch</directive> sont appliqu&eacute;es
-      simultan&eacute;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&eacute;es
-      simultan&eacute;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 &agrave; part les sections <directive type="section"
-    module="core">Directory</directive>, chaque groupe est trait&eacute; selon
-    l'ordre dans lequel il appara&icirc;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&eacute;es dans l'ordre du r&eacute;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>&lt;Directory "/var/web/dir"&gt;</code> sera
-    trait&eacute; avant <code>&lt;Directory
+    traité avant <code>&lt;Directory
     "/var/web/dir/subdir"&gt;</code>.  Si plusieurs sections <directive
-    type="section" module="core">Directory</directive> s'appliquent au m&ecirc;me
-    r&eacute;pertoire, elles sont trait&eacute;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&eacute;es comme si elles se
-    trouvaient r&eacute;ellement dans le fichier qui les inclut &agrave; 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&eacute;es &agrave; l'int&eacute;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&eacute;es <em>apr&egrave;s</em> les sections correspondantes situ&eacute;es en
-    dehors de la d&eacute;finition de l'h&ocirc;te virtuel, ce qui permet &agrave; l'h&ocirc;te virtuel
-    de pr&eacute;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&ecirc;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>&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.
+	</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">
+
+&lt;Directory "/"&gt;
+    Header set CustomHeaderName one
+    &lt;FilesMatch ".*"&gt;
+        Header set CustomHeaderName three
+    &lt;/FilesMatch&gt;
+&lt;/Directory&gt;
 
-    <p>Les sections situ&eacute;es plus loin dans le fichier de configuration pr&eacute;valent
-    sur celles qui les pr&eacute;c&egrave;dent ; cependant, chaque
-    module est responsable de la d&eacute;finition de la forme que doit prendre
-    cette pr&eacute;valence. Une section de configuration ult&eacute;rieure contenant
-    des directives d'un certain module peut &ecirc;tre &agrave; 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&eacute;faut et les directives explicitement d&eacute;finies
-    dans cette section ult&eacute;rieure.</p>
-
-<note><title>Note technique</title>
-	Une s&eacute;quence
-	<code>&lt;Location&gt;</code>/<code>&lt;LocationMatch&gt;</code>
-	est r&eacute;ellement trait&eacute;e juste avant la phase de traduction du nom
-	(o&ugrave; <code>Aliases</code> et <code>DocumentRoots</code>
-      sont utilis&eacute;s pour faire correspondre les URLs aux noms de fichiers).
-      Les effets de cette s&eacute;quence disparaissent totalement lorsque
-      la traduction est termin&eacute;e.
-</note>
+&lt;Directory "/example"&gt;
+    Header set CustomHeaderName two
+&lt;/Directory&gt;
+     
+    </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 &agrave; la requ&ecirc;te, les directives de
-cet exemple seront appliqu&eacute;es dans l'ordre suivant : A &gt; B &gt; C &gt; D &gt;
+En supposant qu'elles s'appliquent toutes à la requête, les directives de
+cet exemple seront appliquées dans l'ordre suivant : A &gt; B &gt; C &gt; D &gt;
 E.</p>
 
 <highlight language="config">
@@ -613,11 +680,11 @@ E.</p>
 
 </highlight>
 
-<p>Pour un exemple plus concret, consid&eacute;rez ce qui suit.  Sans tenir compte
-de toute restriction d'acc&egrave;s plac&eacute;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
-&eacute;valu&eacute;e en dernier et permettra un acc&egrave;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>
 



Mime
View raw message