fr doc rebuild.

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

1 files changed, 44 insertions, 18 deletions

diff --git a/docs/manual/mod/mod_headers.html.fr.utf8 b/docs/manual/mod/mod_headers.html.fr.utf8
index 2a123a6fc6..e57a008353 100644
--- a/docs/manual/mod/mod_headers.html.fr.utf8
+++ b/docs/manual/mod/mod_headers.html.fr.utf8
@@ -248,20 +248,11 @@ version 2.4.10</td></tr>
 
     <p>L'argument optionnel <var>condition</var> permet de déterminer
     sur quelle table interne d'en-têtes de réponses cette directive va
-    opérer. En dépit du nom, la valeur par défaut de
-    <code>onsuccess</code> ne limite <em>pas</em> une <var>action</var>
-    aux réponses avec un code d'état de 2xx. Les en-têtes définis sous
-    cette condition sont encore utilisés quand par exemple une requête
-    est mandatée ou générée par un programme CGI avec <em>succès</em>,
-    et ceci même dans le cas où ils ont généré un code d'échec.</p>
-
-    <p>Lorsque votre action est une fonction agissant sur un en-tête
-    existant, vous pourrez être amené à spécifier une condition
-    <code>always</code>, en fonction de la table interne dans laquelle
-    l'en-tête original a été défini. La table qui correspond à
-    <code>always</code> est utilisée pour les réponses d'erreur générées
-    localement ainsi que pour les réponses qui ont abouti.
-     Notez aussi que la répétition
+    opérer : <code>onsuccess</code> (valeur par défaut, peut être omis) ou
+    <code>always</code>. A la différence de ceux de la première table, les
+    en-têtes de la seconde sont ajoutés à la réponse même en cas d'erreur et
+    sont conservés au fil des redirections internes (par exemple les
+    gestionnaires ErrorDocument). Notez aussi que la répétition
     de cette directive avec les deux conditions peut être pertinente
     dans certains scénarios, car <code>always</code> n'englobe pas
     <code>onsuccess</code> en ce qui concerne les en-têtes existants :</p>
@@ -272,15 +263,42 @@ version 2.4.10</td></tr>
        une redirection par exemple, et dans ce cas, seule la table
        correspondant à <code>always</code> est utilisée dans la réponse
        définitive.</li>
-       <li>Vous modifiez ou supprimez un en-tête généré par un script
-       CGI, et dans ce cas, les scripts CGI sont dans la table
-       correspondant à <code>always</code> et non dans la table par
-       défaut.</li>
+       <li>Vous modifiez ou supprimez un en-tête généré par un script CGI ou par
+       <code class="module"><a href="../mod/mod_proxy_fcgi.html">mod_proxy_fcgi</a></code>, auquel cas, les en-têtes des scripts CGI
+       sont dans la table correspondant à <code>always</code> et non dans la
+       table par défaut.</li>
        <li>Vous modifiez ou supprimez un en-tête généré par tel ou tel
        composant du serveur, mais cet en-tête n'est pas trouvé par la
        condition par défaut <code>onsuccess</code>.</li>
     </ul>
 
+    <p>Comme il n'y a pas de liste unique "normalisée" d'en-têtes, la manière
+    dont httpd stocke en interne les en-têtes des réponses HTTP est à l'origine
+    de la fonctionnalité que constitue la différence entre
+    <code>onsuccess</code> et <code>always</code>. Si vous ne gardez pas à
+    l'esprit le concept ci-après lors de l'écriture de votre configuration,
+    certaines réponses HTTP pourront contenir des en-têtes dupliqués
+    (ce qui pourra dérouter les utilisateurs ou même parfois les clients HTTP). Supposons par
+    exemple que votre configuration comporte un mandataire PHP simple avec
+    <code class="module"><a href="../mod/mod_proxy_fcgi.html">mod_proxy_fcgi</a></code> et que votre script PHP d'arrière-plan
+    ajoute l'en-tête <code>X-Foo: bar</code> à chaque réponse HTTP. Comme décrit
+    plus haut, <code class="module"><a href="../mod/mod_proxy_fcgi.html">mod_proxy_fcgi</a></code> utilise la table
+    <code>always</code> pour stocker les en-têtes, et une configuration comme la
+    suivante n'aboutira pas au résultat attendu car l'en-tête sera dupliqué
+    avec les deux valeurs :</p>
+
+    <pre class="prettyprint lang-config"># la valeur de X-Foo est définie dans la table d'en-têtes 'onsuccess'
+Header set X-Foo: baz</pre>
+    
+
+    <p>Plusieurs modèles de configuration permettent de contourner ce problème,
+    comme celui-ci :</p>
+
+        <pre class="prettyprint lang-config"># 'onsuccess' peut être omis car il s'agit de la valeur par défaut
+Header onsuccess unset X-Foo
+Header always set X-Foo "baz"</pre>
+
+
     <p>Outre le paramètre <var>condition</var> décrit ci-dessus, vous
     pouvez limiter une action en fonction de codes d'état HTTP, par
     exemple pour les requêtes mandatées ou générées par un programme
@@ -292,6 +310,14 @@ version 2.4.10</td></tr>
     <var>condition</var> est spécifiée). Il peut prendre
     une des valeurs suivantes :</p>
 
+    <div class="warning"><h3>Avertissement</h3>
+        <p>Vous devez lire la différence, décrite plus haut, entre les listes
+	d'en-têtes <code>always</code> et <code>onsuccess</code> avant de lire
+	la liste d'actions ci-dessous car cet important concept s'applique
+	encore ici. En fait, chaque action fonctionne telle qu'elle est décrite
+	mais seulement pour la liste d'en-têtes cible.</p>
+    </div>
+
     <dl>
     <dt><code>add</code></dt>
     <dd>L'en-tête est ajouté au jeu d'en-têtes préexistant, même s'il