From: Stefan Fritsch <sf@apache.org>
Date: Sun, 19 Sep 2010 18:28:53 +0000 (+0000)
Subject: Update transformations
X-Git-Tag: 2.3.9~478
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=e7a32264849da8b018fe0e54495de9fd02679a35;p=thirdparty%2Fapache%2Fhttpd.git

Update transformations


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

diff --git a/docs/manual/logs.html.fr b/docs/manual/logs.html.fr
index e0c1a8d037f..a93d4d5e3b2 100644
--- a/docs/manual/logs.html.fr
+++ b/docs/manual/logs.html.fr
@@ -575,6 +575,25 @@
     <p>Comme la journalisation conditionnelle, la journalisation redirigée est
     un outil très puissant, mais si elle existe, il est préférable d'utiliser
     une solution plus simple comme le traitement à posteriori hors ligne.</p>
+
+  <p>Par défaut, le processus de redirection du journal est lancé sans
+  invoquer un shell. Pour invoquer un shell, utilisez "<code>|$</code>"
+  au lieu de "<code>|</code>" (en général avec <code>/bin/sh -c</code>)
+  :</p>
+
+    <div class="example"><p><code>
+      # Invocation de "rotatelogs" en utilisant un shell<br />
+      CustomLog "|$/usr/local/apache/bin/rotatelogs
+      /var/log/access_log 86400" common
+    </code></p></div>
+
+    <p>Il s'agissait du comportement par défaut sous Apache 2.2. Selon
+    les spécificités du shell, ceci peut générer un processus shell
+    supplémentaire pour toute la durée du programme de redirection du
+    journal, et induire des problèmes de gestion de signaux au cours du
+    redémarrage. La notation "<code>||</code>" est aussi supportée pour
+    des raisons de compatibilité avec Apache 2.2 et est équivalente à
+    "<code>|</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="virtualhost" id="virtualhost">Hôtes virtuels</a></h2>
diff --git a/docs/manual/logs.xml.fr b/docs/manual/logs.xml.fr
index 8150dc7522a..031014d659b 100644
--- a/docs/manual/logs.xml.fr
+++ b/docs/manual/logs.xml.fr
@@ -3,7 +3,7 @@
 <?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
 <!-- French translation : Lucien GENTIS -->
 <!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision: 989600 -->
+<!-- English Revision: 989600:992806 (outdated) -->
 
 <!--
  Licensed to the Apache Software Foundation (ASF) under one or more
diff --git a/docs/manual/mod/mod_authz_host.html.en b/docs/manual/mod/mod_authz_host.html.en
index d50f80329f9..c2fa94c1fb2 100644
--- a/docs/manual/mod/mod_authz_host.html.en
+++ b/docs/manual/mod/mod_authz_host.html.en
@@ -209,6 +209,33 @@ address)</td></tr>
 
 
 
+<h3><a name="reqmethod" id="reqmethod">Require method</a></h3>
+
+    <p>The <code>method</code> provider allows to use the HTTP method in
+    authorization decisions. The GET and HEAD methods are treated as
+    equivalent. The TRACE method is not available to this provider,
+    use <code class="directive"><a href="../mod/core.html#traceenable">TraceEnable</a></code> instead.</p>
+
+    <p>The following example will only allow GET, HEAD, POST, and OPTIONS
+    requests:</p>
+
+    <div class="example"><p><code>
+        Require method GET POST OPTIONS<br />
+    </code></p></div>
+
+    <p>The following example will allow GET, HEAD, POST, and OPTIONS
+    requests without authentication, and require a valid user for all other
+    methods:</p>
+
+    <div class="example"><p><code>
+        &lt;RequireAny&gt;<br />
+        &nbsp;Require method GET POST OPTIONS<br />
+        &nbsp;Require valid-user<br />
+        &lt;/RequireAny&gt;<br />
+    </code></p></div>
+
+
+
 
 </div>
 </div>
diff --git a/docs/manual/mod/mod_headers.html.fr b/docs/manual/mod/mod_headers.html.fr
index 4e04d3e2042..74fe5330144 100644
--- a/docs/manual/mod/mod_headers.html.fr
+++ b/docs/manual/mod/mod_headers.html.fr
@@ -384,7 +384,8 @@ est n
     directives <code class="directive">Header</code> sont traitées juste avant
     l'envoi de la réponse sur le réseau. Cela signifie qu'il est
     possible de définir et/ou modifier la plupart des en-têtes, à
-    l'exception de ceux qui sont ajoutés par le filtre d'en-tête.</p>
+    l'exception de ceux qui sont ajoutés par le filtre HTTP
+    d'en-tête, comme Content-Type.</p>
 
 </div>
 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
diff --git a/docs/manual/mod/mod_include.xml.ja b/docs/manual/mod/mod_include.xml.ja
index f283df2a71f..480e4eefa20 100644
--- a/docs/manual/mod/mod_include.xml.ja
+++ b/docs/manual/mod/mod_include.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: 656287:981359 (outdated) -->
+<!-- English Revision: 656287:998651 (outdated) -->
 
 <!--
  Licensed to the Apache Software Foundation (ASF) under one or more
diff --git a/docs/manual/mod/mod_proxy.html.fr b/docs/manual/mod/mod_proxy.html.fr
index ff115db81f9..576cf9187de 100644
--- a/docs/manual/mod/mod_proxy.html.fr
+++ b/docs/manual/mod/mod_proxy.html.fr
@@ -100,6 +100,7 @@
 <li><img alt="" src="../images/down.gif" /> <a href="#forwardreverse">Mandataires directs et
     mandataires/passerelles inverses</a></li>
 <li><img alt="" src="../images/down.gif" /> <a href="#examples">Exemples simples</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#workers">Workers</a></li>
 <li><img alt="" src="../images/down.gif" /> <a href="#access">Contrôler l'accès à votre
     mandataire</a></li>
 <li><img alt="" src="../images/down.gif" /> <a href="#startup">Ralentissement au démarrage</a></li>
@@ -203,6 +204,131 @@
     </code></p></div>
     </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 <div class="section">
+<h2><a name="workers" id="workers">Workers</a></h2>
+      <p>Le mandataire gère la configuration et les paramètres de
+      communication des serveurs originaux au sein d'objets nommés
+      <dfn>workers</dfn>. Deux types de worker sont fournis : le worker
+      par défaut du mandataire direct et le worker par défaut du
+      mandataire inverse. Il est aussi possible de définir explicitement
+      des workers supplémentaires.</p>
+
+      <p>Les deux workers par défaut possèdent une configuration figée
+      et seront utilisés si aucun autre worker ne correspond à la
+      requête. Ils n'utilisent ni les jeux de connexions (connection
+      pooling), ni les
+      connexions HTTP persistantes (Keep-Alive). En effet, les
+      connexions TCP vers le serveur original sont fermées et ouvertes
+      pour chaque requête.</p>
+
+      <p>Les workers définis explicitement sont identifiés par leur URL.
+      Ils sont en général définis via les directives <code class="directive"><a href="#proxypass">ProxyPass</a></code> ou <code class="directive"><a href="#proxypassmatch">ProxyPassMatch</a></code> lorsqu'on les
+      utilise dans le cadre d'un mandataire inverse :</p>
+
+      <div class="example"><p><code>
+          ProxyPass /example http://backend.example.com connectiontimeout=5 timeout=30
+      </code></p></div>
+
+      <p>Cette directive va créer un worker associé à l'URL du serveur
+      original <code>http://backend.example.com</code>, et utilisant les
+      valeurs de timeout données. Lorsqu'ils sont utilisés dans le cadre
+      d'un mandataire direct, les workers sont en général définis via la
+      directive <code class="directive"><a href="#proxyset">ProxySet</a></code>,</p>
+
+      <div class="example"><p><code>
+          ProxySet http://backend.example.com connectiontimeout=5 timeout=30
+      </code></p></div>
+
+      <p>ou encore via les directives <code class="directive"><a href="#proxy">Proxy</a></code> et <code class="directive"><a href="#proxyset">ProxySet</a></code> :</p>
+
+      <div class="example"><p><code>
+        &lt;Proxy http://backend.example.com&gt;<br />
+        <span class="indent">
+          ProxySet connectiontimeout=5 timeout=30
+        </span>
+        &lt;/Proxy&gt;
+      </code></p></div>
+
+      <p>L'utilisation de workers définis explicitement dans le mode
+      mandataire direct n'est pas très courante, car les mandataires
+      directs communiquent en général avec de nombreux serveurs
+      originaux. La création explicite de workers pour certains serveurs
+      originaux peut cependant s'avérer utile si ces serveurs sont
+      très souvent sollicités. A leur niveau, les workers explicitement
+      définis ne possèdent aucune notion de mandataire direct ou
+      inverse. Ils encapsulent un concept de communication commun avec
+      les serveurs originaux. Un worker créé via la directive <code class="directive"><a href="#proxypass">ProxyPass</a></code> pour être utilisé dans le
+      cadre d'un mandataire inverse sera aussi utilisé dans le cadre
+      d'un mandataire directe chaque fois que l'URL vers le serveur
+      original correspondra à l'URL du worker, et vice versa.</p>
+
+      <p>L'URL qui identifie un worker correspond à l'URL de son serveur
+      original, y compris un éventuel chemin donné :</p>
+
+      <div class="example"><p><code>
+          ProxyPass /exemples http://backend.example.com/exemples<br />
+          ProxyPass /docs http://backend.example.com/docs
+      </code></p></div>
+
+      <p>Dans cet exemple, deux workers différents sont définis, chacun
+      d'eux utilisant des configurations et jeux de connexions
+      séparés.</p>
+
+      <div class="warning"><h3>Partage de workers</h3>
+        <p>Le partage de workers intervient lorsque les URLs des workers
+	s'entrecoupent, ce qui arrive lorsque l'URL d'un worker
+	correspond au début de l'URL d'un autre worker défini plus loin
+	dans le fichier de configuration. Dans l'exemple suivant,</p>
+
+        <div class="example"><p><code>
+            ProxyPass /apps http://backend.example.com/ timeout=60<br />
+            ProxyPass /examples http://backend.example.com/exemples timeout=10
+        </code></p></div>
+
+        <p>le second worker n'est pas vraiment créé. C'est le premier
+	worker qui est en fait utilisé. L'avantage de ceci réside dans
+	le fait qu'il n'existe qu'un seul jeu de connexions, ces
+	dernières étant donc réutilisées plus souvent. Notez que tous
+	les attributs de configuration définis explicitement pour le
+	deuxième worker seront ignorés, ce qui sera journalisé en tant
+	qu'avertissement. Ainsi, dans l'exemple ci-dessus, la valeur de
+	timeout retenue pour l'URL <code>/exemples</code> sera
+	<code>60</code>, et non <code>10</code> !</p>
+
+        <p>Si vous voulez empêcher le partage de workers, classez vos
+	définitions de workers selon la longueur des URLs, de la plus
+	longue à la plus courte. Si au contraire vous voulez favoriser
+	ce partage, utilisez l'ordre de classement inverse. Voir aussi
+	l'avertissement à propos de l'ordre de classement des directives
+	<code class="directive"><a href="#proxypass">ProxyPass</a></code>.</p>
+
+      </div> 
+
+      <p>Les workers définis explicitement sont de deux sortes :
+      <dfn>workers directs</dfn> et <dfn>workers de répartition (de
+      charge)</dfn>. Ils supportent de nombreux attributs de
+      configuration importants décrits dans la directive <code class="directive"><a href="#proxypass">ProxyPass</a></code>. Ces mêmes attributs
+      peuvent aussi être définis via la directive <code class="directive"><a href="#proxyset">ProxySet</a></code>.</p>
+
+      <p>Le jeu d'options disponibles pour un worker direct dépend du
+      protocole spécifié dans l'URL du serveur original. Les protocoles
+      disponibles comprennent <code>ajp</code>, <code>fcgi</code>,
+      <code>ftp</code>, <code>http</code> et <code>scgi</code>.</p>
+
+      <p>Les workers de répartition sont des workers virtuels qui
+      utilisent les workers directs, connus comme faisant partie de leurs
+      membres, pour le traitement effectif des requêtes. Chaque
+      répartiteur peut comporter plusieurs membres. Lorsqu'il traite une
+      requête, il choisit un de ses membres en fonction de l'algorithme
+      de répartition de charge défini.</p>
+
+      <p>Un worker de répartition est créé si son URL de worker comporte
+      <code>balancer</code> comme indicateur de protocole. L'URL du
+      répartiteur permet d'identifier de manière unique le worker de
+      répartition. La directive <code class="directive"><a href="#balancermember">BalancerMember</a></code> permet d'ajouter des
+      membres au répartiteur.</p>
+
+    </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
 <h2><a name="access" id="access">Contrôler l'accès à votre
     mandataire</a></h2>
       <p>Vous pouvez restreindre l'accès à votre mandataire via le bloc
@@ -838,11 +964,21 @@ l'espace d'URLs du serveur local</td></tr>
     vers <code>backend.example.com</code>, <em>sauf</em> les requêtes
     pour <code>/miroir/foo/i</code>.</p>
 
-    <div class="note"><h3>Note</h3>
-      <p>L'ordre est important : les exclusions doivent apparaître
-      <em>avant</em> la directive <code class="directive">ProxyPass</code> plus
-      générale.</p>
-    </div>
+    <div class="warning"><h3>Ordre de classement des directives ProxyPass</h3>
+      <p>Les directives <code class="directive"><a href="#proxypass">ProxyPass</a></code> et <code class="directive"><a href="#proxypassmatch">ProxyPassMatch</a></code> sont évaluées dans
+      l'ordre de leur apparition dans le fichier de configuration. La
+      première règle qui correspond s'applique. Vous devez donc en
+      général classer les règles <code class="directive"><a href="#proxypass">ProxyPass</a></code> qui entrent en conflit de
+      l'URL la plus longue à la plus courte. Dans le cas contraire, les
+      règles situées après une règle dont l'URL correspond au début de
+      leur propre URL seront ignorées. Notez que tout ceci est en
+      relation avec le partage de workers.</p>
+
+      <p>Pour les mêmes raisons, les exclusions doivent se situer
+      <em>avant</em> les directives <code class="directive">ProxyPass</code>
+      générales.</p>
+
+    </div> 
 
     <p>Depuis la version 2.1 du serveur HTTP Apache, mod_proxy supporte
     les groupements de connexions vers un serveur d'arrière-plan. Les
@@ -971,17 +1107,24 @@ l'espace d'URLs du serveur local</td></tr>
     </td></tr>
     <tr><td>ping</td>
         <td>0</td>
-        <td>Avec la clé ping, le serveur web envoie une requête
-	<code>CPING</code> sur la connexion ajp13 avant de rediriger une
-	requête. La valeur correspond au délai d'attente de la réponse
-	<code>CPONG</code>. Cette fonctionnalité a été ajoutée afin de
-	pallier aux problèmes de blocage et de surcharge des serveurs
-	Tomcat, et nécessite le support de ping/pong ajp13 qui a été
-	implémenté dans Tomcat 3.3.2+, 4.1.28+ et 5.0.13+. Le trafic
+        <td>Avec la clé Ping, le serveur web va "tester" la connexion
+	vers le serveur d'arrière-plan avant de transmettre la requête.
+	Avec AJP, <code class="module"><a href="../mod/mod_proxy_ajp.html">mod_proxy_ajp</a></code> envoie une requête
+	<code>CPING</code> sur la connexion ajp13 (implémenté sur Tomcat
+	3.3.2+, 4.1.28+ et 5.0.13+). Avec HTTP,
+	<code class="module"><a href="../mod/mod_proxy_http.html">mod_proxy_http</a></code> envoie <code>100-Continue</code>
+	au serveur d'arrière-plan (seulement avecHTTP/1.1 - pour les
+	serveurs d'arrière-plan non HTTP/1.1, cette clé ne produit
+	aucun effet). Dans les deux cas, ce paramètre correspond au
+	délai en secondes pour l'attente de la réponse. Cette
+	fonctionnalité a été ajoutée pour éviter les problèmes avec les
+	serveurs d'arrière-plan bloqués ou surchargés.
+	
+	Le trafic
 	réseau peut s'en trouver augmenté en fonctionnement normal, ce
 	qui peut poser problème, mais peut s'en trouver diminué dans les
-	cas où les noeuds de cluster sont arrêtés ou surchargés. Cette
-	clé n'est actuellement utilisable qu'avec AJP. Le délai peut
+	cas où les noeuds de cluster sont arrêtés ou
+	surchargés. Le délai peut
 	aussi être défini en millisecondes en ajoutant le suffixe
 	ms.
     </td></tr>
@@ -1110,6 +1253,14 @@ l'espace d'URLs du serveur local</td></tr>
 	un serveur cible libre. Le comportement par défaut est de ne pas
 	attendre.
     </td></tr>
+    <tr><td>failonstatus</td>
+        <td>-</td>
+        <td>Une liste de codes d'état HTTP séparés par des virgules. Si
+	ce paramètre est présent, le worker se mettra en erreur si le
+	serveur d'arrière-plan renvoie un des codes d'état spécifiés
+	dans la liste. La récupération du worker s'effectue comme dans
+	le cas des autres erreurs de worker.
+    </td></tr>
 
     </table>
     <p>Exemple de configuration d'un répartiteur de charge</p>
diff --git a/docs/manual/vhosts/ip-based.html.fr b/docs/manual/vhosts/ip-based.html.fr
index 33eceda3924..19275b0ff71 100644
--- a/docs/manual/vhosts/ip-based.html.fr
+++ b/docs/manual/vhosts/ip-based.html.fr
@@ -24,8 +24,6 @@
 <a href="../ko/vhosts/ip-based.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a> |
 <a href="../tr/vhosts/ip-based.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>
 </div>
 <div id="quickview"><ul id="toc"><li><img alt="" src="../images/down.gif" /> <a href="#requirements">Système requis</a></li>
 <li><img alt="" src="../images/down.gif" /> <a href="#howto">Comment configurer Apache</a></li>
@@ -40,13 +38,22 @@ r
 <h2><a name="requirements" id="requirements">Système requis</a></h2>
 
     <p>Comme l'indique le terme <cite>par IP</cite>, le serveur
-    <strong>doit disposer de différentes adresses IP pour chaque
+    <strong>doit disposer de différentes paires adresses IP/port pour chaque
     serveur virtuel par IP</strong>. La machine peut posséder
     plusieurs connexions physiques au réseau, ou utiliser des
     interfaces virtuelles qui sont supportées par la plupart des
     systèmes d'exploitation modernes (Consultez la documentation des
     systèmes d'exploitation pour plus de détails, notamment les "alias
-    IP" et la commande "ifconfig" pour les activer).</p>
+    IP" et la commande "ifconfig" pour les activer), et/ou utiliser
+    plusieurs numéros de port.</p>
+
+    <p>Dans la plupart des cas, les <a href="name-based.html">serveurs
+    virtuels à base de nom</a> sont plus appropriés, car ils permettent
+    de partager une seule paire adresse/port entre de nombreux serveurs
+    virtuels. Voir le document <a href="name-based.html#namevip">Serveurs virtuels à base de noms ou
+    serveurs virtuels à base d'adresse IP</a> pour vous aider à prendre
+    une décision.
+    </p>
 
 </div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 <div class="section">
diff --git a/docs/manual/vhosts/ip-based.xml.meta b/docs/manual/vhosts/ip-based.xml.meta
index 03687ce26fb..d3c670cc20c 100644
--- a/docs/manual/vhosts/ip-based.xml.meta
+++ b/docs/manual/vhosts/ip-based.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>
diff --git a/docs/manual/vhosts/name-based.html.fr b/docs/manual/vhosts/name-based.html.fr
index 5426ed24570..0ecffcf9e68 100644
--- a/docs/manual/vhosts/name-based.html.fr
+++ b/docs/manual/vhosts/name-based.html.fr
@@ -25,8 +25,6 @@
 <a href="../ko/vhosts/name-based.html" hreflang="ko" rel="alternate" title="Korean">&nbsp;ko&nbsp;</a> |
 <a href="../tr/vhosts/name-based.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>Ce document décrit quand et comment utiliser des serveurs 
     virtuels par nom.</p>
@@ -38,12 +36,13 @@
 <div class="section">
 <h2><a name="namevip" id="namevip">Serveurs virtuels par nom vs. par IP</a></h2>
 
-    <p>Les hébergements virtuels par IP utilisent l'adresse IP 
+    <p>Les <a href="ip-based.html">serveurs virtuels</a> par IP utilisent l'adresse IP 
     de la connexion afin de déterminer quel serveur virtuel doit 
     répondre. Par conséquent, vous devez disposer d'adresses IP 
-    différentes pour chaque serveur. 
-    Avec un hébergement 
-    virtuel par nom, le serveur s'appuit sur les informations 
+    différentes pour chaque serveur.</p>
+
+    <p>Avec un hébergement 
+    virtuel par nom, le serveur s'appuie sur les informations 
     transmises par le client dans les en-têtes HTTP de ses requêtes. 
     La technique présentée ici vous permet de disposer de serveurs 
     virtuels différents partagés sur une même adresse IP.</p>
@@ -59,8 +58,8 @@
     sont exposées ci-après&nbsp;:</p>
 
     <ul>
-        <li>L'hébergement virtuel par nom ne peut pas être utilisé 
-        avec des serveurs sécurisés SSL à cause de la nature même 
+        <li>L'hébergement virtuel par nom <a href="../ssl/ssl_faq.html#vhosts">ne peut pas être utilisé 
+        avec des serveurs sécurisés SSL</a> à cause de la nature même 
         du protocole SSL.</li>
 
         <li>Certains systèmes d'exploitation et équipements réseaux 
@@ -77,22 +76,25 @@
 
     <p>Pour utiliser des serveurs virtuels par nom, vous devez 
     désigner l'adresse IP (et si possible le port) sur le serveur 
-    devant accepter les requêtes pour des domaines. Cette 
+    devant accepter les requêtes qui doivent être redirigées en fonction
+    du nom d'hôte. Cette 
     configuration utilise la directive 
     <code class="directive"><a href="../mod/core.html#namevirtualhost">NameVirtualHost</a></code>. Dans un 
     cas normal où n'importe quelle adresse IP peut être utilisée, 
     vous pouvez ajouter <code>*</code> comme argument de la directive 
     <code class="directive"><a href="../mod/core.html#namevirtualhost">NameVirtualHost</a></code>. Si vous 
     prévoyez d'utiliser de multiples ports (comme l'emploi de SSL), 
-    vous devriez ajouter le port à cet argument tel que 
-    <code>*:80</code>. Notez que la simple mention d'une adresse 
+    vous devez ajouter le port à cet argument tel que 
+    <code>*:80</code>.</p>
+    
+    <div class="note"><p>Notez que la simple mention d'une adresse 
     IP dans une directive 
     <code class="directive"><a href="../mod/core.html#namevirtualhost">NameVirtualHost</a></code> ne suffit 
-    pas à faire écouter le serveur sur cette IP. Consultez 
+    pas à faire <em>écouter</em> le serveur sur cette IP. Consultez 
     <a href="../bind.html">Définition des adresses et ports qu'utilise
     Apache</a> pour plus 
     de détails. Par ailleurs, chaque adresse IP spécifiée ici doit 
-    être associée avec une interface réseau sur le serveur.</p>
+    être associée avec une interface réseau sur le serveur.</p></div>
 
     <p>L'étape suivante est la création d'une section 
     <code class="directive"><a href="../mod/core.html#virtualhost">&lt;VirtualHost&gt;</a></code> 
diff --git a/docs/manual/vhosts/name-based.xml.meta b/docs/manual/vhosts/name-based.xml.meta
index d9e8b42809d..ab8307c0f37 100644
--- a/docs/manual/vhosts/name-based.xml.meta
+++ b/docs/manual/vhosts/name-based.xml.meta
@@ -9,7 +9,7 @@
   <variants>
     <variant outdated="yes">de</variant>
     <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>