httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From c...@apache.org
Subject svn commit: r1673892 [17/36] - in /httpd/httpd/trunk/docs/manual: ./ developer/ howto/ misc/ mod/ platform/ rewrite/ vhosts/
Date Wed, 15 Apr 2015 17:46:57 GMT
Modified: httpd/httpd/trunk/docs/manual/mod/mod_file_cache.html.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_file_cache.html.fr?rev=1673892&r1=1673891&r2=1673892&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_file_cache.html.fr (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_file_cache.html.fr Wed Apr 15 17:46:53 2015
@@ -67,81 +67,15 @@ fichiers</td></tr>
     <p>Ce module est une extension et s'inspire fortement du module
     d'Apache 1.3 <code>mod_mmap_static</code>.</p>
 </div>
-<div id="quickview"><h3 class="directives">Directives</h3>
+<div id="quickview"><h3>Sujets</h3>
+<ul id="topics">
+<li><img alt="" src="../images/down.gif" /> <a href="#using">Utilisation de mod_file_cache</a></li>
+</ul><h3 class="directives">Directives</h3>
 <ul id="toc">
 <li><img alt="" src="../images/down.gif" /> <a href="#cachefile">CacheFile</a></li>
 <li><img alt="" src="../images/down.gif" /> <a href="#mmapfile">MMapFile</a></li>
 </ul>
-<h3>Sujets</h3>
-<ul id="topics">
-<li><img alt="" src="../images/down.gif" /> <a href="#using">Utilisation de mod_file_cache</a></li>
-</ul><ul class="seealso"><li><a href="#comments_section">Commentaires</a></li></ul></div>
-<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="directive-section"><h2><a name="cachefile" id="cachefile">Directive</a> <a name="CacheFile" id="CacheFile">CacheFile</a></h2>
-<table class="directive">
-<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Met en cache une liste de gestionnaires de fichiers au
-démarrage</td></tr>
-<tr><th><a href="directive-dict.html#Syntax">Syntaxe:</a></th><td><code>CacheFile <var>chemin_fichier</var> [<var>chemin fichier</var>] ...</code></td></tr>
-<tr><th><a href="directive-dict.html#Context">Contexte:</a></th><td>configuration du serveur</td></tr>
-<tr><th><a href="directive-dict.html#Status">Statut:</a></th><td>Expérimental</td></tr>
-<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_file_cache</td></tr>
-</table>
-    <p>La directive <code class="directive">CacheFile</code> associe
-    des gestionnaires à un ou plusieurs fichiers (séparés par des
-    espaces), et place ceux-ci dans le cache au démarrage du
-    serveur. Les gestionnaires des fichiers mis en cache sont
-    automatiquement fermés à l'arrêt du serveur. Lorsqu'un ou plusieurs
-    fichiers ont été modifiés sur disque, le serveur doit être redémarré
-    afin que les modifications soient prises en compte par le cache.</p>
-
-    <p>Soyez prudent avec les arguments <var>chemin_fichier</var> : ils
-    doivent correspondre exactement au chemin du système de fichier que
-    créent les gestionnaires de traduction URL-vers-nom-fichier
-    d'Apache. On ne peut pas comparer des inodes ou autres identifiants
-    pour mettre en correspondance des chemins à l'aide de liens
-    symboliques <em>(etc...)</em>, car là encore, ceci nécessiterait un
-    appel à <code>stat()</code> supplémentaire, ce qui est inacceptable.
-    Il n'est pas garanti que ce module fonctionne avec des noms de
-    fichiers réécrits par <code class="module"><a href="../mod/mod_alias.html">mod_alias</a></code> ou
-    <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>.</p>
-
-    <div class="example"><h3>Exemple</h3><pre class="prettyprint lang-config">CacheFile /usr/local/apache/htdocs/index.html</pre>
-</div>
-
-</div>
-<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="directive-section"><h2><a name="mmapfile" id="mmapfile">Directive</a> <a name="MMapFile" id="MMapFile">MMapFile</a></h2>
-<table class="directive">
-<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Charge au démarrage une liste de fichiers en
-mémoire</td></tr>
-<tr><th><a href="directive-dict.html#Syntax">Syntaxe:</a></th><td><code>MMapFile <var>chemin fichier</var> [<var>chemin_fichier</var>] ...</code></td></tr>
-<tr><th><a href="directive-dict.html#Context">Contexte:</a></th><td>configuration du serveur</td></tr>
-<tr><th><a href="directive-dict.html#Status">Statut:</a></th><td>Expérimental</td></tr>
-<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_file_cache</td></tr>
-</table>
-    <p>La directive <code class="directive">MMapFile</code> provoque le chargement d'un
-    ou plusieurs fichiers (séparés par des espaces) en mémoire au
-    démarrage du serveur. Ceux-ci sont automatiquement déchargés de la
-    mémoire à l'arrêt du serveur. Lorsqu'un ou plusieurs fichiers ont
-    été modifiés sur disque, on doit au minimum envoyer un signal
-    <code>HUP</code> ou <code>USR1</code> au serveur afin de les
-    re<code>mmap()</code>er.</p>
-
-    <p>Soyez prudent avec les arguments <var>chemin_fichier</var> : ils
-    doivent correspondre exactement au chemin du système de fichier que
-    créent les gestionnaires de traduction URL-vers-nom-fichier
-    d'Apache. On ne peut pas comparer des inodes ou autres identifiants
-    pour mettre en correspondance des chemins à l'aide de liens
-    symboliques <em>(etc...)</em>, car là encore, ceci nécessiterait un
-    appel à <code>stat()</code> supplémentaire, ce qui est inacceptable.
-    Il n'est pas garanti que ce module fonctionne avec des noms de
-    fichiers réécrits par <code class="module"><a href="../mod/mod_alias.html">mod_alias</a></code> ou
-    <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>.</p>
-
-    <div class="example"><h3>Exemple</h3><pre class="prettyprint lang-config">MMapFile /usr/local/apache/htdocs/index.html</pre>
-</div>
-
-</div>
+<ul class="seealso"><li><a href="#comments_section">Commentaires</a></li></ul></div>
 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 <div class="section">
 <h2><a name="using" id="using">Utilisation de mod_file_cache</a></h2>
@@ -234,6 +168,72 @@ mémoire</td></tr>
       </code></p></div>
     </div>
 </div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="directive-section"><h2><a name="cachefile" id="cachefile">Directive</a> <a name="CacheFile" id="CacheFile">CacheFile</a></h2>
+<table class="directive">
+<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Met en cache une liste de gestionnaires de fichiers au
+démarrage</td></tr>
+<tr><th><a href="directive-dict.html#Syntax">Syntaxe:</a></th><td><code>CacheFile <var>chemin_fichier</var> [<var>chemin fichier</var>] ...</code></td></tr>
+<tr><th><a href="directive-dict.html#Context">Contexte:</a></th><td>configuration du serveur</td></tr>
+<tr><th><a href="directive-dict.html#Status">Statut:</a></th><td>Expérimental</td></tr>
+<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_file_cache</td></tr>
+</table>
+    <p>La directive <code class="directive">CacheFile</code> associe
+    des gestionnaires à un ou plusieurs fichiers (séparés par des
+    espaces), et place ceux-ci dans le cache au démarrage du
+    serveur. Les gestionnaires des fichiers mis en cache sont
+    automatiquement fermés à l'arrêt du serveur. Lorsqu'un ou plusieurs
+    fichiers ont été modifiés sur disque, le serveur doit être redémarré
+    afin que les modifications soient prises en compte par le cache.</p>
+
+    <p>Soyez prudent avec les arguments <var>chemin_fichier</var> : ils
+    doivent correspondre exactement au chemin du système de fichier que
+    créent les gestionnaires de traduction URL-vers-nom-fichier
+    d'Apache. On ne peut pas comparer des inodes ou autres identifiants
+    pour mettre en correspondance des chemins à l'aide de liens
+    symboliques <em>(etc...)</em>, car là encore, ceci nécessiterait un
+    appel à <code>stat()</code> supplémentaire, ce qui est inacceptable.
+    Il n'est pas garanti que ce module fonctionne avec des noms de
+    fichiers réécrits par <code class="module"><a href="../mod/mod_alias.html">mod_alias</a></code> ou
+    <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>.</p>
+
+    <div class="example"><h3>Exemple</h3><pre class="prettyprint lang-config">CacheFile /usr/local/apache/htdocs/index.html</pre>
+</div>
+
+</div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="directive-section"><h2><a name="mmapfile" id="mmapfile">Directive</a> <a name="MMapFile" id="MMapFile">MMapFile</a></h2>
+<table class="directive">
+<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Charge au démarrage une liste de fichiers en
+mémoire</td></tr>
+<tr><th><a href="directive-dict.html#Syntax">Syntaxe:</a></th><td><code>MMapFile <var>chemin fichier</var> [<var>chemin_fichier</var>] ...</code></td></tr>
+<tr><th><a href="directive-dict.html#Context">Contexte:</a></th><td>configuration du serveur</td></tr>
+<tr><th><a href="directive-dict.html#Status">Statut:</a></th><td>Expérimental</td></tr>
+<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>mod_file_cache</td></tr>
+</table>
+    <p>La directive <code class="directive">MMapFile</code> provoque le chargement d'un
+    ou plusieurs fichiers (séparés par des espaces) en mémoire au
+    démarrage du serveur. Ceux-ci sont automatiquement déchargés de la
+    mémoire à l'arrêt du serveur. Lorsqu'un ou plusieurs fichiers ont
+    été modifiés sur disque, on doit au minimum envoyer un signal
+    <code>HUP</code> ou <code>USR1</code> au serveur afin de les
+    re<code>mmap()</code>er.</p>
+
+    <p>Soyez prudent avec les arguments <var>chemin_fichier</var> : ils
+    doivent correspondre exactement au chemin du système de fichier que
+    créent les gestionnaires de traduction URL-vers-nom-fichier
+    d'Apache. On ne peut pas comparer des inodes ou autres identifiants
+    pour mettre en correspondance des chemins à l'aide de liens
+    symboliques <em>(etc...)</em>, car là encore, ceci nécessiterait un
+    appel à <code>stat()</code> supplémentaire, ce qui est inacceptable.
+    Il n'est pas garanti que ce module fonctionne avec des noms de
+    fichiers réécrits par <code class="module"><a href="../mod/mod_alias.html">mod_alias</a></code> ou
+    <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>.</p>
+
+    <div class="example"><h3>Exemple</h3><pre class="prettyprint lang-config">MMapFile /usr/local/apache/htdocs/index.html</pre>
+</div>
+
+</div>
 </div>
 <div class="bottomlang">
 <p><span>Langues Disponibles: </span><a href="../en/mod/mod_file_cache.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |

Modified: httpd/httpd/trunk/docs/manual/mod/mod_file_cache.html.ko.euc-kr
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_file_cache.html.ko.euc-kr?rev=1673892&r1=1673891&r2=1673892&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_file_cache.html.ko.euc-kr [euc-kr] (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_file_cache.html.ko.euc-kr [euc-kr] Wed Apr 15 17:46:53 2015
@@ -61,72 +61,15 @@
     <p>이 모듈은 아파치 1.3에 있는 <code>mod_mmap_static</code>
     모듈의 기능을 확장한 결과다.</p>
 </div>
-<div id="quickview"><h3 class="directives">지시어들</h3>
+<div id="quickview"><h3>주제</h3>
+<ul id="topics">
+<li><img alt="" src="../images/down.gif" /> <a href="#using">mod_file_cache 사용하기</a></li>
+</ul><h3 class="directives">지시어들</h3>
 <ul id="toc">
 <li><img alt="" src="../images/down.gif" /> <a href="#cachefile">CacheFile</a></li>
 <li><img alt="" src="../images/down.gif" /> <a href="#mmapfile">MMapFile</a></li>
 </ul>
-<h3>주제</h3>
-<ul id="topics">
-<li><img alt="" src="../images/down.gif" /> <a href="#using">mod_file_cache 사용하기</a></li>
-</ul><ul class="seealso"><li><a href="#comments_section">Comments</a></li></ul></div>
-<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="directive-section"><h2><a name="CacheFile" id="CacheFile">CacheFile</a> <a name="cachefile" id="cachefile">지시어</a></h2>
-<table class="directive">
-<tr><th><a href="directive-dict.html#Description">설명:</a></th><td>시작시 여러 파일 핸들을 캐쉬한다</td></tr>
-<tr><th><a href="directive-dict.html#Syntax">문법:</a></th><td><code>CacheFile <var>file-path</var> [<var>file-path</var>] ...</code></td></tr>
-<tr><th><a href="directive-dict.html#Context">사용장소:</a></th><td>주서버설정</td></tr>
-<tr><th><a href="directive-dict.html#Status">상태:</a></th><td>Experimental</td></tr>
-<tr><th><a href="directive-dict.html#Module">모듈:</a></th><td>mod_file_cache</td></tr>
-</table>
-    <p><code class="directive">CacheFile</code> 지시어는 서버가 시작할때
-    여러 파일을 열고(open) 파일들의 핸들을 캐쉬에 저장한다.
-    서버 종료시 자동으로 캐쉬한 파일의 핸들을 닫는다(close).
-    파일시스템에서 파일이 변경되면 파일을 다시 캐쉬하기위해
-    서버를 재시작해야 한다.</p>
-
-    <p><var>file-path</var> 아규먼트를 조심해라. 아규먼트는
-    아파치의 URL-파일명 변환 핸들러가 만든 파일시스템 경로와
-    정확히 일치해야 한다. 한번 더 불필요한 <code>stat()</code>
-    시스템호출이 필요하기때문에 inode나 심볼링크 <em>등</em>을
-    경로를 지정할 수 없다. 이 모듈은 <code class="module"><a href="../mod/mod_alias.html">mod_alias</a></code>나
-    <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>로 재작성한 파일명을 다룰 수
-    있기도 없기도 하다.</p>
-
-    <div class="example"><h3>예제</h3><p><code>
-      CacheFile /usr/local/apache/htdocs/index.html
-    </code></p></div>
-
-</div>
-<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="directive-section"><h2><a name="MMapFile" id="MMapFile">MMapFile</a> <a name="mmapfile" id="mmapfile">지시어</a></h2>
-<table class="directive">
-<tr><th><a href="directive-dict.html#Description">설명:</a></th><td>시작시 여러 파일을 메모리에 대응한다</td></tr>
-<tr><th><a href="directive-dict.html#Syntax">문법:</a></th><td><code>MMapFile <var>file-path</var> [<var>file-path</var>] ...</code></td></tr>
-<tr><th><a href="directive-dict.html#Context">사용장소:</a></th><td>주서버설정</td></tr>
-<tr><th><a href="directive-dict.html#Status">상태:</a></th><td>Experimental</td></tr>
-<tr><th><a href="directive-dict.html#Module">모듈:</a></th><td>mod_file_cache</td></tr>
-</table>
-    <p><code class="directive">MMapFile</code> 지시어는 서버가 시작할때
-    (공백으로 구분한 아규먼트로 지정한) 여러 파일을 메모리에
-    대응한다(map). 서버 종료시 자동으로 대응을 푼다(unmap).
-    파일시스템에서 파일이 변경되면 파일들을 다시
-    <code>mmap()</code>하기위해 최소한 서버에 <code>HUP</code>이나
-    <code>USR1</code> 시그널을 보내야 한다.</p>
-
-    <p><var>file-path</var> 아규먼트를 조심해라. 아규먼트는
-    아파치의 URL-파일명 변환 핸들러가 만든 파일시스템 경로와
-    정확히 일치해야 한다. 한번 더 불필요한 <code>stat()</code>
-    시스템호출이 필요하기때문에 inode나 심볼링크 <em>등</em>을
-    경로를 지정할 수 없다. 이 모듈은 <code class="module"><a href="../mod/mod_alias.html">mod_alias</a></code>나
-    <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>로 재작성한 파일명을 다룰 수
-    있기도 없기도 하다.</p>
-
-    <div class="example"><h3>예제</h3><p><code>
-      MMapFile /usr/local/apache/htdocs/index.html
-    </code></p></div>
-
-</div>
+<ul class="seealso"><li><a href="#comments_section">Comments</a></li></ul></div>
 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 <div class="section">
 <h2><a name="using" id="using">mod_file_cache 사용하기</a></h2>
@@ -196,6 +139,63 @@
       </code></p></div>
     </div>
 </div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="directive-section"><h2><a name="CacheFile" id="CacheFile">CacheFile</a> <a name="cachefile" id="cachefile">지시어</a></h2>
+<table class="directive">
+<tr><th><a href="directive-dict.html#Description">설명:</a></th><td>시작시 여러 파일 핸들을 캐쉬한다</td></tr>
+<tr><th><a href="directive-dict.html#Syntax">문법:</a></th><td><code>CacheFile <var>file-path</var> [<var>file-path</var>] ...</code></td></tr>
+<tr><th><a href="directive-dict.html#Context">사용장소:</a></th><td>주서버설정</td></tr>
+<tr><th><a href="directive-dict.html#Status">상태:</a></th><td>Experimental</td></tr>
+<tr><th><a href="directive-dict.html#Module">모듈:</a></th><td>mod_file_cache</td></tr>
+</table>
+    <p><code class="directive">CacheFile</code> 지시어는 서버가 시작할때
+    여러 파일을 열고(open) 파일들의 핸들을 캐쉬에 저장한다.
+    서버 종료시 자동으로 캐쉬한 파일의 핸들을 닫는다(close).
+    파일시스템에서 파일이 변경되면 파일을 다시 캐쉬하기위해
+    서버를 재시작해야 한다.</p>
+
+    <p><var>file-path</var> 아규먼트를 조심해라. 아규먼트는
+    아파치의 URL-파일명 변환 핸들러가 만든 파일시스템 경로와
+    정확히 일치해야 한다. 한번 더 불필요한 <code>stat()</code>
+    시스템호출이 필요하기때문에 inode나 심볼링크 <em>등</em>을
+    경로를 지정할 수 없다. 이 모듈은 <code class="module"><a href="../mod/mod_alias.html">mod_alias</a></code>나
+    <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>로 재작성한 파일명을 다룰 수
+    있기도 없기도 하다.</p>
+
+    <div class="example"><h3>예제</h3><p><code>
+      CacheFile /usr/local/apache/htdocs/index.html
+    </code></p></div>
+
+</div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="directive-section"><h2><a name="MMapFile" id="MMapFile">MMapFile</a> <a name="mmapfile" id="mmapfile">지시어</a></h2>
+<table class="directive">
+<tr><th><a href="directive-dict.html#Description">설명:</a></th><td>시작시 여러 파일을 메모리에 대응한다</td></tr>
+<tr><th><a href="directive-dict.html#Syntax">문법:</a></th><td><code>MMapFile <var>file-path</var> [<var>file-path</var>] ...</code></td></tr>
+<tr><th><a href="directive-dict.html#Context">사용장소:</a></th><td>주서버설정</td></tr>
+<tr><th><a href="directive-dict.html#Status">상태:</a></th><td>Experimental</td></tr>
+<tr><th><a href="directive-dict.html#Module">모듈:</a></th><td>mod_file_cache</td></tr>
+</table>
+    <p><code class="directive">MMapFile</code> 지시어는 서버가 시작할때
+    (공백으로 구분한 아규먼트로 지정한) 여러 파일을 메모리에
+    대응한다(map). 서버 종료시 자동으로 대응을 푼다(unmap).
+    파일시스템에서 파일이 변경되면 파일들을 다시
+    <code>mmap()</code>하기위해 최소한 서버에 <code>HUP</code>이나
+    <code>USR1</code> 시그널을 보내야 한다.</p>
+
+    <p><var>file-path</var> 아규먼트를 조심해라. 아규먼트는
+    아파치의 URL-파일명 변환 핸들러가 만든 파일시스템 경로와
+    정확히 일치해야 한다. 한번 더 불필요한 <code>stat()</code>
+    시스템호출이 필요하기때문에 inode나 심볼링크 <em>등</em>을
+    경로를 지정할 수 없다. 이 모듈은 <code class="module"><a href="../mod/mod_alias.html">mod_alias</a></code>나
+    <code class="module"><a href="../mod/mod_rewrite.html">mod_rewrite</a></code>로 재작성한 파일명을 다룰 수
+    있기도 없기도 하다.</p>
+
+    <div class="example"><h3>예제</h3><p><code>
+      MMapFile /usr/local/apache/htdocs/index.html
+    </code></p></div>
+
+</div>
 </div>
 <div class="bottomlang">
 <p><span>가능한 언어: </span><a href="../en/mod/mod_file_cache.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |

Modified: httpd/httpd/trunk/docs/manual/mod/mod_filter.html.en
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_filter.html.en?rev=1673892&r1=1673891&r2=1673892&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_filter.html.en (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_filter.html.en Wed Apr 15 17:46:53 2015
@@ -64,6 +64,200 @@
 </ul>
 <ul class="seealso"><li><a href="#comments_section">Comments</a></li></ul></div>
 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="smart" id="smart">Smart Filtering</a></h2>
+    <p>In the traditional filtering model, filters are inserted unconditionally
+    using <code class="directive"><a href="../mod/mod_mime.html#addoutputfilter">AddOutputFilter</a></code> and family.
+    Each filter then needs to determine whether to run, and there is little
+    flexibility available for server admins to allow the chain to be
+    configured dynamically.</p>
+
+    <p><code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> by contrast gives server administrators a
+    great deal of flexibility in configuring the filter chain.  In fact,
+    filters can be inserted based on complex boolean
+    <a href="../expr.html">expressions</a> This generalises the limited
+    flexibility offered by <code class="directive">AddOutputFilterByType</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="terms" id="terms">Filter Declarations, Providers and Chains</a></h2>
+    <p class="figure">
+    <img src="../images/mod_filter_old.gif" width="160" height="310" alt="[This image displays the traditional filter model]" /><br />
+    <dfn>Figure 1:</dfn> The traditional filter model</p>
+
+    <p>In the traditional model, output filters are a simple chain
+    from the content generator (handler) to the client.  This works well
+    provided the filter chain can be correctly configured, but presents
+    problems when the filters need to be configured dynamically based on
+    the outcome of the handler.</p>
+
+    <p class="figure">
+    <img src="../images/mod_filter_new.gif" width="423" height="331" alt="[This image shows the mod_filter model]" /><br />
+    <dfn>Figure 2:</dfn> The <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> model</p>
+
+    <p><code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> works by introducing indirection into
+    the filter chain.  Instead of inserting filters in the chain, we insert
+    a filter harness which in turn dispatches conditionally
+    to a filter provider.  Any content filter may be used as a provider
+    to <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code>; no change to existing filter modules
+    is required (although it may be possible to simplify them).  There can be
+    multiple providers for one filter, but no more than one provider will
+    run for any single request.</p>
+
+    <p>A filter chain comprises any number of instances of the filter
+    harness, each of which may have any number of providers.  A special
+    case is that of a single provider with unconditional dispatch: this
+    is equivalent to inserting the provider filter directly into the chain.</p>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="config" id="config">Configuring the Chain</a></h2>
+    <p>There are three stages to configuring a filter chain with
+    <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code>. For details of the directives, see below.</p>
+
+    <dl>
+    <dt>Declare Filters</dt>
+    <dd>The <code class="directive"><a href="#filterdeclare">FilterDeclare</a></code> directive
+    declares a filter, assigning it a name and filter type.  Required
+    only if the filter is not the default type AP_FTYPE_RESOURCE.</dd>
+
+    <dt>Register Providers</dt>
+    <dd>The <code class="directive"><a href="#filterprovider">FilterProvider</a></code>
+    directive registers a provider with a filter. The filter may have
+    been declared with <code class="directive"><a href="#filterdeclare">FilterDeclare</a></code>; if not, FilterProvider will implicitly
+    declare it with the default type AP_FTYPE_RESOURCE. The provider
+    must have been
+    registered with <code>ap_register_output_filter</code> by some module.
+    The final argument to <code class="directive"><a href="#filterprovider">FilterProvider</a></code> is an expression: the provider will be
+    selected to run for a request if and only if the expression evaluates
+    to true.  The expression may evaluate HTTP request or response
+    headers, environment variables, or the Handler used by this request.
+    Unlike earlier versions, mod_filter now supports complex expressions
+    involving multiple criteria with AND / OR logic (&amp;&amp; / ||)
+    and brackets. The details of the expression syntax are described in
+    the <a href="../expr.html">ap_expr documentation</a>.</dd>
+
+    <dt>Configure the Chain</dt>
+    <dd>The above directives build components of a smart filter chain,
+    but do not configure it to run.  The <code class="directive"><a href="#filterchain">FilterChain</a></code> directive builds a filter chain from smart
+    filters declared, offering the flexibility to insert filters at the
+    beginning or end of the chain, remove a filter, or clear the chain.</dd>
+</dl>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="errordocs" id="errordocs">Filtering and Response Status</a></h2>
+    <p>mod_filter normally only runs filters on responses with
+    HTTP status 200 (OK).  If you want to filter documents with
+    other response statuses, you can set the <var>filter-errordocs</var>
+    environment variable, and it will work on all responses
+    regardless of status.  To refine this further, you can use
+    expression conditions with <code class="directive">FilterProvider</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="upgrade" id="upgrade">Upgrading from Apache HTTP Server 2.2 Configuration</a></h2>
+    <p>The <code class="directive"><a href="#filterprovider">FilterProvider</a></code>
+    directive has changed from httpd 2.2: the <var>match</var> and
+    <var>dispatch</var> arguments are replaced with a single but
+    more versatile <var>expression</var>.  In general, you can convert
+    a match/dispatch pair to the two sides of an expression, using
+    something like:</p>
+    <div class="example"><p><code>"dispatch = 'match'"</code></p></div>
+    <p>The Request headers, Response headers and Environment variables
+    are now interpreted from syntax <var>%{req:foo}</var>,
+    <var>%{resp:foo}</var> and <var>%{env:foo}</var> respectively.
+    The variables <var>%{HANDLER}</var> and <var>%{CONTENT_TYPE}</var>
+    are also supported.</p>
+    <p>Note that the match no longer support substring matches.  They can be
+    replaced by regular expression matches.</p>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="examples" id="examples">Examples</a></h2>
+    <dl>
+    <dt>Server side Includes (SSI)</dt>
+    <dd>A simple case of replacing <code class="directive">AddOutputFilterByType</code>
+    <pre class="prettyprint lang-config">FilterDeclare SSI
+FilterProvider SSI INCLUDES "%{CONTENT_TYPE} =~ m|^text/html|"
+FilterChain SSI</pre>
+
+    </dd>
+
+    <dt>Server side Includes (SSI)</dt>
+    <dd>The same as the above but dispatching on handler (classic
+    SSI behaviour; .shtml files get processed).
+    <pre class="prettyprint lang-config">FilterProvider SSI INCLUDES "%{HANDLER} = 'server-parsed'"
+FilterChain SSI</pre>
+
+    </dd>
+
+    <dt>Emulating mod_gzip with mod_deflate</dt>
+    <dd>Insert INFLATE filter only if "gzip" is NOT in the
+    Accept-Encoding header.  This filter runs with ftype CONTENT_SET.
+    <pre class="prettyprint lang-config">FilterDeclare gzip CONTENT_SET
+FilterProvider gzip inflate "%{req:Accept-Encoding} !~ /gzip/"
+FilterChain gzip</pre>
+
+    </dd>
+
+    <dt>Image Downsampling</dt>
+    <dd>Suppose we want to downsample all web images, and have filters
+    for GIF, JPEG and PNG.
+    <pre class="prettyprint lang-config">FilterProvider unpack jpeg_unpack "%{CONTENT_TYPE} = 'image/jpeg'"
+FilterProvider unpack gif_unpack "%{CONTENT_TYPE} = 'image/gif'"
+FilterProvider unpack png_unpack "%{CONTENT_TYPE} = 'image/png'"
+
+FilterProvider downsample downsample_filter "%{CONTENT_TYPE} = m|^image/(jpeg|gif|png)|"
+FilterProtocol downsample "change=yes"
+
+FilterProvider repack jpeg_pack "%{CONTENT_TYPE} = 'image/jpeg'"
+FilterProvider repack gif_pack "%{CONTENT_TYPE} = 'image/gif'"
+FilterProvider repack png_pack "%{CONTENT_TYPE} = 'image/png'"
+&lt;Location "/image-filter"&gt;
+    FilterChain unpack downsample repack
+&lt;/Location&gt;</pre>
+
+    </dd>
+    </dl>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="protocol" id="protocol">Protocol Handling</a></h2>
+    <p>Historically, each filter is responsible for ensuring that whatever
+    changes it makes are correctly represented in the HTTP response headers,
+    and that it does not run when it would make an illegal change.  This
+    imposes a burden on filter authors to re-implement some common
+    functionality in every filter:</p>
+
+    <ul>
+    <li>Many filters will change the content, invalidating existing content
+    tags, checksums, hashes, and lengths.</li>
+
+    <li>Filters that require an entire, unbroken response in input need to
+    ensure they don't get byteranges from a backend.</li>
+
+    <li>Filters that transform output in a filter need to ensure they don't
+    violate a <code>Cache-Control: no-transform</code> header from the
+    backend.</li>
+
+    <li>Filters may make responses uncacheable.</li>
+    </ul>
+
+    <p><code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> aims to offer generic handling of these
+    details of filter implementation, reducing the complexity required of
+    content filter modules. This is work-in-progress; the
+    <code class="directive"><a href="#filterprotocol">FilterProtocol</a></code> implements
+    some of this functionality for back-compatibility with Apache 2.0
+    modules.  For httpd 2.1 and later, the
+    <code>ap_register_output_filter_protocol</code> and
+    <code>ap_filter_protocol</code> API enables filter modules to
+    declare their own behaviour.</p>
+
+    <p>At the same time, <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> should not interfere
+    with a filter that wants to handle all aspects of the protocol.  By
+    default (i.e. in the absence of any <code class="directive"><a href="#filterprotocol">FilterProtocol</a></code> directives), <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code>
+    will leave the headers untouched.</p>
+
+    <p>At the time of writing, this feature is largely untested,
+    as modules in common use are designed to work with 2.0.
+    Modules using it should test it carefully.</p>
+</div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 <div class="directive-section"><h2><a name="AddOutputFilterByType" id="AddOutputFilterByType">AddOutputFilterByType</a> <a name="addoutputfilterbytype" id="addoutputfilterbytype">Directive</a></h2>
 <table class="directive">
 <tr><th><a href="directive-dict.html#Description">Description:</a></th><td>assigns an output filter to a particular media-type</td></tr>
@@ -98,7 +292,7 @@ being moved to <code class="module"><a h
     <code>INCLUDES</code> filter and then by the <code>DEFLATE</code>
     filter.</p>
 
-    <pre class="prettyprint lang-config">&lt;Location /cgi-bin/&gt;
+    <pre class="prettyprint lang-config">&lt;Location "/cgi-bin/"&gt;
     Options Includes
     AddOutputFilterByType INCLUDES;DEFLATE text/html
 &lt;/Location&gt;</pre>
@@ -294,200 +488,6 @@ for a complete reference and examples.</
     </dl>
 
 </div>
-<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="smart" id="smart">Smart Filtering</a></h2>
-    <p>In the traditional filtering model, filters are inserted unconditionally
-    using <code class="directive"><a href="../mod/mod_mime.html#addoutputfilter">AddOutputFilter</a></code> and family.
-    Each filter then needs to determine whether to run, and there is little
-    flexibility available for server admins to allow the chain to be
-    configured dynamically.</p>
-
-    <p><code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> by contrast gives server administrators a
-    great deal of flexibility in configuring the filter chain.  In fact,
-    filters can be inserted based on complex boolean
-    <a href="../expr.html">expressions</a> This generalises the limited
-    flexibility offered by <code class="directive">AddOutputFilterByType</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="terms" id="terms">Filter Declarations, Providers and Chains</a></h2>
-    <p class="figure">
-    <img src="../images/mod_filter_old.gif" width="160" height="310" alt="[This image displays the traditional filter model]" /><br />
-    <dfn>Figure 1:</dfn> The traditional filter model</p>
-
-    <p>In the traditional model, output filters are a simple chain
-    from the content generator (handler) to the client.  This works well
-    provided the filter chain can be correctly configured, but presents
-    problems when the filters need to be configured dynamically based on
-    the outcome of the handler.</p>
-
-    <p class="figure">
-    <img src="../images/mod_filter_new.gif" width="423" height="331" alt="[This image shows the mod_filter model]" /><br />
-    <dfn>Figure 2:</dfn> The <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> model</p>
-
-    <p><code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> works by introducing indirection into
-    the filter chain.  Instead of inserting filters in the chain, we insert
-    a filter harness which in turn dispatches conditionally
-    to a filter provider.  Any content filter may be used as a provider
-    to <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code>; no change to existing filter modules
-    is required (although it may be possible to simplify them).  There can be
-    multiple providers for one filter, but no more than one provider will
-    run for any single request.</p>
-
-    <p>A filter chain comprises any number of instances of the filter
-    harness, each of which may have any number of providers.  A special
-    case is that of a single provider with unconditional dispatch: this
-    is equivalent to inserting the provider filter directly into the chain.</p>
-</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="config" id="config">Configuring the Chain</a></h2>
-    <p>There are three stages to configuring a filter chain with
-    <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code>. For details of the directives, see below.</p>
-
-    <dl>
-    <dt>Declare Filters</dt>
-    <dd>The <code class="directive"><a href="#filterdeclare">FilterDeclare</a></code> directive
-    declares a filter, assigning it a name and filter type.  Required
-    only if the filter is not the default type AP_FTYPE_RESOURCE.</dd>
-
-    <dt>Register Providers</dt>
-    <dd>The <code class="directive"><a href="#filterprovider">FilterProvider</a></code>
-    directive registers a provider with a filter. The filter may have
-    been declared with <code class="directive"><a href="#filterdeclare">FilterDeclare</a></code>; if not, FilterProvider will implicitly
-    declare it with the default type AP_FTYPE_RESOURCE. The provider
-    must have been
-    registered with <code>ap_register_output_filter</code> by some module.
-    The final argument to <code class="directive"><a href="#filterprovider">FilterProvider</a></code> is an expression: the provider will be
-    selected to run for a request if and only if the expression evaluates
-    to true.  The expression may evaluate HTTP request or response
-    headers, environment variables, or the Handler used by this request.
-    Unlike earlier versions, mod_filter now supports complex expressions
-    involving multiple criteria with AND / OR logic (&amp;&amp; / ||)
-    and brackets. The details of the expression syntax are described in
-    the <a href="../expr.html">ap_expr documentation</a>.</dd>
-
-    <dt>Configure the Chain</dt>
-    <dd>The above directives build components of a smart filter chain,
-    but do not configure it to run.  The <code class="directive"><a href="#filterchain">FilterChain</a></code> directive builds a filter chain from smart
-    filters declared, offering the flexibility to insert filters at the
-    beginning or end of the chain, remove a filter, or clear the chain.</dd>
-</dl>
-</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="errordocs" id="errordocs">Filtering and Response Status</a></h2>
-    <p>mod_filter normally only runs filters on responses with
-    HTTP status 200 (OK).  If you want to filter documents with
-    other response statuses, you can set the <var>filter-errordocs</var>
-    environment variable, and it will work on all responses
-    regardless of status.  To refine this further, you can use
-    expression conditions with <code class="directive">FilterProvider</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="upgrade" id="upgrade">Upgrading from Apache HTTP Server 2.2 Configuration</a></h2>
-    <p>The <code class="directive"><a href="#filterprovider">FilterProvider</a></code>
-    directive has changed from httpd 2.2: the <var>match</var> and
-    <var>dispatch</var> arguments are replaced with a single but
-    more versatile <var>expression</var>.  In general, you can convert
-    a match/dispatch pair to the two sides of an expression, using
-    something like:</p>
-    <div class="example"><p><code>"dispatch = 'match'"</code></p></div>
-    <p>The Request headers, Response headers and Environment variables
-    are now interpreted from syntax <var>%{req:foo}</var>,
-    <var>%{resp:foo}</var> and <var>%{env:foo}</var> respectively.
-    The variables <var>%{HANDLER}</var> and <var>%{CONTENT_TYPE}</var>
-    are also supported.</p>
-    <p>Note that the match no longer support substring matches.  They can be
-    replaced by regular expression matches.</p>
-</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="examples" id="examples">Examples</a></h2>
-    <dl>
-    <dt>Server side Includes (SSI)</dt>
-    <dd>A simple case of replacing <code class="directive">AddOutputFilterByType</code>
-    <pre class="prettyprint lang-config">FilterDeclare SSI
-FilterProvider SSI INCLUDES "%{CONTENT_TYPE} =~ m|^text/html|"
-FilterChain SSI</pre>
-
-    </dd>
-
-    <dt>Server side Includes (SSI)</dt>
-    <dd>The same as the above but dispatching on handler (classic
-    SSI behaviour; .shtml files get processed).
-    <pre class="prettyprint lang-config">FilterProvider SSI INCLUDES "%{HANDLER} = 'server-parsed'"
-FilterChain SSI</pre>
-
-    </dd>
-
-    <dt>Emulating mod_gzip with mod_deflate</dt>
-    <dd>Insert INFLATE filter only if "gzip" is NOT in the
-    Accept-Encoding header.  This filter runs with ftype CONTENT_SET.
-    <pre class="prettyprint lang-config">FilterDeclare gzip CONTENT_SET
-FilterProvider gzip inflate "%{req:Accept-Encoding} !~ /gzip/"
-FilterChain gzip</pre>
-
-    </dd>
-
-    <dt>Image Downsampling</dt>
-    <dd>Suppose we want to downsample all web images, and have filters
-    for GIF, JPEG and PNG.
-    <pre class="prettyprint lang-config">FilterProvider unpack jpeg_unpack "%{CONTENT_TYPE} = 'image/jpeg'"
-FilterProvider unpack gif_unpack "%{CONTENT_TYPE} = 'image/gif'"
-FilterProvider unpack png_unpack "%{CONTENT_TYPE} = 'image/png'"
-
-FilterProvider downsample downsample_filter "%{CONTENT_TYPE} = m|^image/(jpeg|gif|png)|"
-FilterProtocol downsample "change=yes"
-
-FilterProvider repack jpeg_pack "%{CONTENT_TYPE} = 'image/jpeg'"
-FilterProvider repack gif_pack "%{CONTENT_TYPE} = 'image/gif'"
-FilterProvider repack png_pack "%{CONTENT_TYPE} = 'image/png'"
-&lt;Location /image-filter&gt;
-    FilterChain unpack downsample repack
-&lt;/Location&gt;</pre>
-
-    </dd>
-    </dl>
-</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="protocol" id="protocol">Protocol Handling</a></h2>
-    <p>Historically, each filter is responsible for ensuring that whatever
-    changes it makes are correctly represented in the HTTP response headers,
-    and that it does not run when it would make an illegal change.  This
-    imposes a burden on filter authors to re-implement some common
-    functionality in every filter:</p>
-
-    <ul>
-    <li>Many filters will change the content, invalidating existing content
-    tags, checksums, hashes, and lengths.</li>
-
-    <li>Filters that require an entire, unbroken response in input need to
-    ensure they don't get byteranges from a backend.</li>
-
-    <li>Filters that transform output in a filter need to ensure they don't
-    violate a <code>Cache-Control: no-transform</code> header from the
-    backend.</li>
-
-    <li>Filters may make responses uncacheable.</li>
-    </ul>
-
-    <p><code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> aims to offer generic handling of these
-    details of filter implementation, reducing the complexity required of
-    content filter modules. This is work-in-progress; the
-    <code class="directive"><a href="#filterprotocol">FilterProtocol</a></code> implements
-    some of this functionality for back-compatibility with Apache 2.0
-    modules.  For httpd 2.1 and later, the
-    <code>ap_register_output_filter_protocol</code> and
-    <code>ap_filter_protocol</code> API enables filter modules to
-    declare their own behaviour.</p>
-
-    <p>At the same time, <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code> should not interfere
-    with a filter that wants to handle all aspects of the protocol.  By
-    default (i.e. in the absence of any <code class="directive"><a href="#filterprotocol">FilterProtocol</a></code> directives), <code class="module"><a href="../mod/mod_filter.html">mod_filter</a></code>
-    will leave the headers untouched.</p>
-
-    <p>At the time of writing, this feature is largely untested,
-    as modules in common use are designed to work with 2.0.
-    Modules using it should test it carefully.</p>
-</div>
 </div>
 <div class="bottomlang">
 <p><span>Available Languages: </span><a href="../en/mod/mod_filter.html" title="English">&nbsp;en&nbsp;</a></p>

Modified: httpd/httpd/trunk/docs/manual/mod/mod_filter.xml
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_filter.xml?rev=1673892&r1=1673891&r2=1673892&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_filter.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_filter.xml Wed Apr 15 17:46:53 2015
@@ -193,7 +193,7 @@ FilterProtocol downsample "change=yes"
 FilterProvider repack jpeg_pack "%{CONTENT_TYPE} = 'image/jpeg'"
 FilterProvider repack gif_pack "%{CONTENT_TYPE} = 'image/gif'"
 FilterProvider repack png_pack "%{CONTENT_TYPE} = 'image/png'"
-&lt;Location /image-filter&gt;
+&lt;Location "/image-filter"&gt;
     FilterChain unpack downsample repack
 &lt;/Location&gt;
     </highlight>
@@ -281,7 +281,7 @@ being moved to <module>mod_filter</modul
     filter.</p>
 
     <highlight language="config">
-&lt;Location /cgi-bin/&gt;
+&lt;Location "/cgi-bin/"&gt;
     Options Includes
     AddOutputFilterByType INCLUDES;DEFLATE text/html
 &lt;/Location&gt;

Modified: httpd/httpd/trunk/docs/manual/mod/mod_firehose.html.en
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_firehose.html.en?rev=1673892&r1=1673891&r2=1673892&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_firehose.html.en (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_firehose.html.en Wed Apr 15 17:46:53 2015
@@ -70,6 +70,96 @@
 <li><code class="program"><a href="../programs/firehose.html">firehose</a></code></li>
 </ul><ul class="seealso"><li><a href="#comments_section">Comments</a></li></ul></div>
 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="enable" id="enable">Enabling a Firehose</a></h2>
+    
+
+    <p>To enable the module, it should be compiled and loaded
+    in to your running Apache configuration, and the directives below
+    used to record the data you are interested in.</p>
+    
+    <p>It is possible to record both incoming and outgoing data to
+    the same filename if desired, as the direction of flow is recorded
+    within each fragment.</p>
+
+    <p>It is possible to write to both normal files and fifos (pipes).
+    In the case of fifos, mod_firehose ensures that the packet size is
+    no larger than PIPE_BUF to ensure writes are atomic.</p>
+
+    <p>If a pipe is being used, something must be reading from the pipe
+    before httpd is started for the pipe to be successfully opened for
+    write. If the request to open the pipe fails, mod_firehose will
+    silently stand down and not record anything, and the server will
+    keep running as normal.</p>
+
+    <p>By default, all attempts to write will block the server. If the
+    webserver has been built against APR v2.0 or later, and an optional
+    "nonblock" parameter is specified all file writes will be non
+    blocking, and buffer overflows will cause debugging data to be lost.
+    In this case it is possible to prioritise the running of the server
+    over the recording of firehose data.</p>
+
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="format" id="format">Stream Format</a></h2>
+    
+
+    <p>The server typically serves multiple connections simultaneously,
+    and as a result requests and responses need to be multiplexed before
+    being written to the firehose.</p>
+    
+    <p>The fragment format is designed as clear text, so that a firehose
+    can be opened with and inspected by a normal text editor.
+    Alternatively, the <code class="program"><a href="../programs/firehose.html">firehose</a></code> tool can be used to
+    demultiplex the firehose back into individual requests or
+    connections.</p>
+
+    <p>The size of the multiplexed fragments is governed by PIPE_BUF,
+    the maximum size of write the system is prepared to perform
+    atomically. By keeping the multiplexed fragments below PIPE_BUF in
+    size, the module guarantees that data from different fragments does
+    not interleave. The size of PIPE_BUF varies on different operating
+    systems.</p>
+
+    <p>The BNF for the fragment format is as follows:</p>
+
+    <pre> stream = 0*(fragment)
+
+ fragment = header CRLF body CRLF
+
+ header = length SPC timestamp SPC ( request | response ) SPC uuid SPC count
+
+ length = &lt;up to 16 byte hex fragment length&gt;
+ timestamp = &lt;up to 16 byte hex timestamp microseconds since 1970&gt;
+ request = "&lt;"
+ response = "&gt;"
+ uuid = &lt;formatted uuid of the connection&gt;
+ count = &lt;hex fragment number in the connection&gt;
+
+ body = &lt;the binary content of the fragment&gt;
+
+ SPC = &lt;a single space&gt;
+ CRLF = &lt;a carriage return, followed by a line feed&gt;</pre>
+
+    <p>All fragments for a connection or a request will share the same
+    UUID, depending on whether connections or requests are being recorded.
+    If connections are being recorded, multiple requests may appear within
+    a connection. A fragment with a zero length indicates the end of the
+    connection.</p>
+
+    <p>Fragments may go missing or be dropped if the process reading the
+    fragments is too slow. If this happens, gaps will exist in the
+    connection counter numbering. A warning will be logged in the error
+    log to indicate the UUID and counter of the dropped fragment, so it
+    can be confirmed the fragment was dropped.</p>
+
+    <p>It is possible that the terminating empty fragment may not appear,
+    caused by the httpd process crashing, or being terminated ungracefully.
+    The terminating fragment may be dropped if the process reading the
+    fragments is not fast enough.</p>
+
+</div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 <div class="directive-section"><h2><a name="FirehoseConnectionInput" id="FirehoseConnectionInput">FirehoseConnectionInput</a> <a name="firehoseconnectioninput" id="firehoseconnectioninput">Directive</a></h2>
 <table class="directive">
 <tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Capture traffic coming into the server on each connection</td></tr>
@@ -183,96 +273,6 @@ later.</td></tr>
 </div>
 
 </div>
-<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="enable" id="enable">Enabling a Firehose</a></h2>
-    
-
-    <p>To enable the module, it should be compiled and loaded
-    in to your running Apache configuration, and the directives below
-    used to record the data you are interested in.</p>
-    
-    <p>It is possible to record both incoming and outgoing data to
-    the same filename if desired, as the direction of flow is recorded
-    within each fragment.</p>
-
-    <p>It is possible to write to both normal files and fifos (pipes).
-    In the case of fifos, mod_firehose ensures that the packet size is
-    no larger than PIPE_BUF to ensure writes are atomic.</p>
-
-    <p>If a pipe is being used, something must be reading from the pipe
-    before httpd is started for the pipe to be successfully opened for
-    write. If the request to open the pipe fails, mod_firehose will
-    silently stand down and not record anything, and the server will
-    keep running as normal.</p>
-
-    <p>By default, all attempts to write will block the server. If the
-    webserver has been built against APR v2.0 or later, and an optional
-    "nonblock" parameter is specified all file writes will be non
-    blocking, and buffer overflows will cause debugging data to be lost.
-    In this case it is possible to prioritise the running of the server
-    over the recording of firehose data.</p>
-
-</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="format" id="format">Stream Format</a></h2>
-    
-
-    <p>The server typically serves multiple connections simultaneously,
-    and as a result requests and responses need to be multiplexed before
-    being written to the firehose.</p>
-    
-    <p>The fragment format is designed as clear text, so that a firehose
-    can be opened with and inspected by a normal text editor.
-    Alternatively, the <code class="program"><a href="../programs/firehose.html">firehose</a></code> tool can be used to
-    demultiplex the firehose back into individual requests or
-    connections.</p>
-
-    <p>The size of the multiplexed fragments is governed by PIPE_BUF,
-    the maximum size of write the system is prepared to perform
-    atomically. By keeping the multiplexed fragments below PIPE_BUF in
-    size, the module guarantees that data from different fragments does
-    not interleave. The size of PIPE_BUF varies on different operating
-    systems.</p>
-
-    <p>The BNF for the fragment format is as follows:</p>
-
-    <pre> stream = 0*(fragment)
-
- fragment = header CRLF body CRLF
-
- header = length SPC timestamp SPC ( request | response ) SPC uuid SPC count
-
- length = &lt;up to 16 byte hex fragment length&gt;
- timestamp = &lt;up to 16 byte hex timestamp microseconds since 1970&gt;
- request = "&lt;"
- response = "&gt;"
- uuid = &lt;formatted uuid of the connection&gt;
- count = &lt;hex fragment number in the connection&gt;
-
- body = &lt;the binary content of the fragment&gt;
-
- SPC = &lt;a single space&gt;
- CRLF = &lt;a carriage return, followed by a line feed&gt;</pre>
-
-    <p>All fragments for a connection or a request will share the same
-    UUID, depending on whether connections or requests are being recorded.
-    If connections are being recorded, multiple requests may appear within
-    a connection. A fragment with a zero length indicates the end of the
-    connection.</p>
-
-    <p>Fragments may go missing or be dropped if the process reading the
-    fragments is too slow. If this happens, gaps will exist in the
-    connection counter numbering. A warning will be logged in the error
-    log to indicate the UUID and counter of the dropped fragment, so it
-    can be confirmed the fragment was dropped.</p>
-
-    <p>It is possible that the terminating empty fragment may not appear,
-    caused by the httpd process crashing, or being terminated ungracefully.
-    The terminating fragment may be dropped if the process reading the
-    fragments is not fast enough.</p>
-
-</div>
 </div>
 <div class="bottomlang">
 <p><span>Available Languages: </span><a href="../en/mod/mod_firehose.html" title="English">&nbsp;en&nbsp;</a></p>

Modified: httpd/httpd/trunk/docs/manual/mod/mod_headers.html.en
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_headers.html.en?rev=1673892&r1=1673891&r2=1673892&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_headers.html.en (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_headers.html.en Wed Apr 15 17:46:53 2015
@@ -52,6 +52,158 @@ headers</td></tr>
 </ul>
 <ul class="seealso"><li><a href="#comments_section">Comments</a></li></ul></div>
 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="order" id="order">Order of Processing</a></h2>
+
+    <p>The directives provided by <code class="module"><a href="../mod/mod_headers.html">mod_headers</a></code> can
+    occur almost anywhere within the server configuration, and can be
+    limited in scope by enclosing them in <a href="../sections.html">configuration sections</a>.</p>
+
+    <p>Order of processing is important and is affected both by the
+    order in the configuration file and by placement in <a href="../sections.html#mergin">configuration sections</a>. These
+    two directives have a different effect if reversed:</p>
+
+    <pre class="prettyprint lang-config">RequestHeader append MirrorID "mirror 12"
+RequestHeader unset MirrorID</pre>
+
+
+    <p>This way round, the <code>MirrorID</code> header is not set. If
+    reversed, the MirrorID header is set to "mirror 12".</p>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="early" id="early">Early and Late Processing</a></h2>
+    <p><code class="module"><a href="../mod/mod_headers.html">mod_headers</a></code> can be applied either early or late
+    in the request.  The normal mode is late, when <em>Request</em> Headers are
+    set immediately before running the content generator and <em>Response</em>
+    Headers just as the response is sent down the wire.  Always use
+    Late mode in an operational server.</p>
+
+    <p>Early mode is designed as a test/debugging aid for developers.
+    Directives defined using the <code>early</code> keyword are set
+    right at the beginning of processing the request.  This means
+    they can be used to simulate different requests and set up test
+    cases, but it also means that headers may be changed at any time
+    by other modules before generating a Response.</p>
+
+    <p>Because early directives are processed before the request path's
+    configuration is traversed, early headers can only be set in a
+    main server or virtual host context.  Early directives cannot depend
+    on a request path, so they will fail in contexts such as
+    <code class="directive"><a href="../mod/core.html#directory">&lt;Directory&gt;</a></code> or
+    <code class="directive"><a href="../mod/core.html#location">&lt;Location&gt;</a></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="examples" id="examples">Examples</a></h2>
+
+    <ol>
+      <li>
+        Copy all request headers that begin with "TS" to the
+        response headers:
+
+        <pre class="prettyprint lang-config">Header echo ^TS</pre>
+
+      </li>
+
+      <li>
+        Add a header, <code>MyHeader</code>, to the response including a
+        timestamp for when the request was received and how long it
+        took to begin serving the request. This header can be used by
+        the client to intuit load on the server or in isolating
+        bottlenecks between the client and the server.
+
+        <pre class="prettyprint lang-config">Header set MyHeader "%D %t"</pre>
+
+
+        <p>results in this header being added to the response:</p>
+
+        <div class="example"><p><code>
+          MyHeader: D=3775428 t=991424704447256
+        </code></p></div>
+      </li>
+
+      <li>
+        Say hello to Joe
+
+        <pre class="prettyprint lang-config">Header set MyHeader "Hello Joe. It took %D microseconds for Apache to serve this request."</pre>
+
+
+        <p>results in this header being added to the response:</p>
+
+        <div class="example"><p><code>
+          MyHeader: Hello Joe. It took D=3775428 microseconds for Apache
+          to serve this request.
+        </code></p></div>
+      </li>
+
+      <li>
+        Conditionally send <code>MyHeader</code> on the response if and
+        only if header <code>MyRequestHeader</code> is present on the request.
+        This is useful for constructing headers in response to some client
+        stimulus. Note that this example requires the services of the
+        <code class="module"><a href="../mod/mod_setenvif.html">mod_setenvif</a></code> module.
+
+        <pre class="prettyprint lang-config">SetEnvIf MyRequestHeader myvalue HAVE_MyRequestHeader
+Header set MyHeader "%D %t mytext" env=HAVE_MyRequestHeader</pre>
+
+
+        <p>If the header <code>MyRequestHeader: myvalue</code> is present on
+        the HTTP request, the response will contain the following header:</p>
+
+        <div class="example"><p><code>
+          MyHeader: D=3775428 t=991424704447256 mytext
+        </code></p></div>
+      </li>
+
+      <li>
+        Enable DAV to work with Apache running HTTP through SSL hardware
+        (<a href="http://svn.haxx.se/users/archive-2006-03/0549.shtml">problem
+        description</a>) by replacing <var>https:</var> with
+        <var>http:</var> in the <var>Destination</var> header:
+
+        <pre class="prettyprint lang-config">RequestHeader edit Destination ^https: http: early</pre>
+
+      </li>
+
+      <li>
+        Set the same header value under multiple nonexclusive conditions,
+        but do not duplicate the value in the final header.
+        If all of the following conditions applied to a request (i.e.,
+        if the <code>CGI</code>, <code>NO_CACHE</code> and
+        <code>NO_STORE</code> environment variables all existed for the
+        request):
+
+        <pre class="prettyprint lang-config">Header merge Cache-Control no-cache env=CGI
+Header merge Cache-Control no-cache env=NO_CACHE
+Header merge Cache-Control no-store env=NO_STORE</pre>
+
+
+        <p>then the response would contain the following header:</p>
+
+        <div class="example"><p><code>
+          Cache-Control: no-cache, no-store
+        </code></p></div>
+
+        <p>If <code>append</code> was used instead of <code>merge</code>,
+        then the response would contain the following header:</p>
+
+        <div class="example"><p><code>
+          Cache-Control: no-cache, no-cache, no-store
+        </code></p></div>
+      </li>
+      <li>
+        Set a test cookie if and only if the client didn't send us a cookie
+        <pre class="prettyprint lang-config">Header set Set-Cookie testcookie "expr=-z %{req:Cookie}"</pre>
+
+      </li>
+      <li>
+        Append a Caching header for responses with a HTTP status code of 200
+        <pre class="prettyprint lang-config">Header append Cache-Control s-maxage=600 "expr=%{REQUEST_STATUS} == 200"</pre>
+
+      </li>
+
+    </ol>
+</div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 <div class="directive-section"><h2><a name="Header" id="Header">Header</a> <a name="header" id="header">Directive</a></h2>
 <table class="directive">
 <tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Configure HTTP response headers</td></tr>
@@ -392,158 +544,6 @@ available in 2.4.10 and later</td></tr>
     input filters to be overridden or modified.</p>
 
 </div>
-<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="order" id="order">Order of Processing</a></h2>
-
-    <p>The directives provided by <code class="module"><a href="../mod/mod_headers.html">mod_headers</a></code> can
-    occur almost anywhere within the server configuration, and can be
-    limited in scope by enclosing them in <a href="../sections.html">configuration sections</a>.</p>
-
-    <p>Order of processing is important and is affected both by the
-    order in the configuration file and by placement in <a href="../sections.html#mergin">configuration sections</a>. These
-    two directives have a different effect if reversed:</p>
-
-    <pre class="prettyprint lang-config">RequestHeader append MirrorID "mirror 12"
-RequestHeader unset MirrorID</pre>
-
-
-    <p>This way round, the <code>MirrorID</code> header is not set. If
-    reversed, the MirrorID header is set to "mirror 12".</p>
-</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="early" id="early">Early and Late Processing</a></h2>
-    <p><code class="module"><a href="../mod/mod_headers.html">mod_headers</a></code> can be applied either early or late
-    in the request.  The normal mode is late, when <em>Request</em> Headers are
-    set immediately before running the content generator and <em>Response</em>
-    Headers just as the response is sent down the wire.  Always use
-    Late mode in an operational server.</p>
-
-    <p>Early mode is designed as a test/debugging aid for developers.
-    Directives defined using the <code>early</code> keyword are set
-    right at the beginning of processing the request.  This means
-    they can be used to simulate different requests and set up test
-    cases, but it also means that headers may be changed at any time
-    by other modules before generating a Response.</p>
-
-    <p>Because early directives are processed before the request path's
-    configuration is traversed, early headers can only be set in a
-    main server or virtual host context.  Early directives cannot depend
-    on a request path, so they will fail in contexts such as
-    <code class="directive"><a href="../mod/core.html#directory">&lt;Directory&gt;</a></code> or
-    <code class="directive"><a href="../mod/core.html#location">&lt;Location&gt;</a></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="examples" id="examples">Examples</a></h2>
-
-    <ol>
-      <li>
-        Copy all request headers that begin with "TS" to the
-        response headers:
-
-        <pre class="prettyprint lang-config">Header echo ^TS</pre>
-
-      </li>
-
-      <li>
-        Add a header, <code>MyHeader</code>, to the response including a
-        timestamp for when the request was received and how long it
-        took to begin serving the request. This header can be used by
-        the client to intuit load on the server or in isolating
-        bottlenecks between the client and the server.
-
-        <pre class="prettyprint lang-config">Header set MyHeader "%D %t"</pre>
-
-
-        <p>results in this header being added to the response:</p>
-
-        <div class="example"><p><code>
-          MyHeader: D=3775428 t=991424704447256
-        </code></p></div>
-      </li>
-
-      <li>
-        Say hello to Joe
-
-        <pre class="prettyprint lang-config">Header set MyHeader "Hello Joe. It took %D microseconds for Apache to serve this request."</pre>
-
-
-        <p>results in this header being added to the response:</p>
-
-        <div class="example"><p><code>
-          MyHeader: Hello Joe. It took D=3775428 microseconds for Apache
-          to serve this request.
-        </code></p></div>
-      </li>
-
-      <li>
-        Conditionally send <code>MyHeader</code> on the response if and
-        only if header <code>MyRequestHeader</code> is present on the request.
-        This is useful for constructing headers in response to some client
-        stimulus. Note that this example requires the services of the
-        <code class="module"><a href="../mod/mod_setenvif.html">mod_setenvif</a></code> module.
-
-        <pre class="prettyprint lang-config">SetEnvIf MyRequestHeader myvalue HAVE_MyRequestHeader
-Header set MyHeader "%D %t mytext" env=HAVE_MyRequestHeader</pre>
-
-
-        <p>If the header <code>MyRequestHeader: myvalue</code> is present on
-        the HTTP request, the response will contain the following header:</p>
-
-        <div class="example"><p><code>
-          MyHeader: D=3775428 t=991424704447256 mytext
-        </code></p></div>
-      </li>
-
-      <li>
-        Enable DAV to work with Apache running HTTP through SSL hardware
-        (<a href="http://svn.haxx.se/users/archive-2006-03/0549.shtml">problem
-        description</a>) by replacing <var>https:</var> with
-        <var>http:</var> in the <var>Destination</var> header:
-
-        <pre class="prettyprint lang-config">RequestHeader edit Destination ^https: http: early</pre>
-
-      </li>
-
-      <li>
-        Set the same header value under multiple nonexclusive conditions,
-        but do not duplicate the value in the final header.
-        If all of the following conditions applied to a request (i.e.,
-        if the <code>CGI</code>, <code>NO_CACHE</code> and
-        <code>NO_STORE</code> environment variables all existed for the
-        request):
-
-        <pre class="prettyprint lang-config">Header merge Cache-Control no-cache env=CGI
-Header merge Cache-Control no-cache env=NO_CACHE
-Header merge Cache-Control no-store env=NO_STORE</pre>
-
-
-        <p>then the response would contain the following header:</p>
-
-        <div class="example"><p><code>
-          Cache-Control: no-cache, no-store
-        </code></p></div>
-
-        <p>If <code>append</code> was used instead of <code>merge</code>,
-        then the response would contain the following header:</p>
-
-        <div class="example"><p><code>
-          Cache-Control: no-cache, no-cache, no-store
-        </code></p></div>
-      </li>
-      <li>
-        Set a test cookie if and only if the client didn't send us a cookie
-        <pre class="prettyprint lang-config">Header set Set-Cookie testcookie "expr=-z %{req:Cookie}"</pre>
-
-      </li>
-      <li>
-        Append a Caching header for responses with a HTTP status code of 200
-        <pre class="prettyprint lang-config">Header append Cache-Control s-maxage=600 "expr=%{REQUEST_STATUS} == 200"</pre>
-
-      </li>
-
-    </ol>
-</div>
 </div>
 <div class="bottomlang">
 <p><span>Available Languages: </span><a href="../en/mod/mod_headers.html" title="English">&nbsp;en&nbsp;</a> |

Modified: httpd/httpd/trunk/docs/manual/mod/mod_headers.html.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_headers.html.fr?rev=1673892&r1=1673891&r2=1673892&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_headers.html.fr (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_headers.html.fr Wed Apr 15 17:46:53 2015
@@ -40,18 +40,185 @@ HTTP</td></tr>
     modifier les en-têtes de requêtes et de réponses HTTP. Les en-têtes
     peuvent être fusionnés, remplacés ou supprimés.</p>
 </div>
-<div id="quickview"><h3 class="directives">Directives</h3>
-<ul id="toc">
-<li><img alt="" src="../images/down.gif" /> <a href="#header">Header</a></li>
-<li><img alt="" src="../images/down.gif" /> <a href="#requestheader">RequestHeader</a></li>
-</ul>
-<h3>Sujets</h3>
+<div id="quickview"><h3>Sujets</h3>
 <ul id="topics">
 <li><img alt="" src="../images/down.gif" /> <a href="#order">Chronologie du traitement</a></li>
 <li><img alt="" src="../images/down.gif" /> <a href="#early">Traitement précoce et traitement
 tardif</a></li>
 <li><img alt="" src="../images/down.gif" /> <a href="#examples">Exemples</a></li>
-</ul><ul class="seealso"><li><a href="#comments_section">Commentaires</a></li></ul></div>
+</ul><h3 class="directives">Directives</h3>
+<ul id="toc">
+<li><img alt="" src="../images/down.gif" /> <a href="#header">Header</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#requestheader">RequestHeader</a></li>
+</ul>
+<ul class="seealso"><li><a href="#comments_section">Commentaires</a></li></ul></div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="order" id="order">Chronologie du traitement</a></h2>
+
+    <p>Les directives fournies par <code class="module"><a href="../mod/mod_headers.html">mod_headers</a></code> peuvent
+    s'insérer presque partout dans la configuration du serveur, et on
+    peut limiter leur portée en les plaçant dans des <a href="../sections.html">sections de configuration</a>.</p>
+
+    <p>La chronologie du traitement est importante et est affectée par
+    l'ordre d'apparition des directives dans le fichier de configuration
+    et par leur placement dans les <a href="../sections.html#mergin">sections de configuration</a>. Ainsi,
+    ces deux directives ont un effet différent si leur ordre est inversé
+    :</p>
+
+    <pre class="prettyprint lang-config">RequestHeader append MirrorID "mirror 12"
+RequestHeader unset MirrorID</pre>
+
+
+    <p>Dans cet ordre, l'en-tête <code>MirrorID</code> n'est pas défini.
+    Si l'ordre des directives était inversé, l'en-tête
+    <code>MirrorID</code> serait défini à "mirror 12".</p>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="early" id="early">Traitement précoce et traitement
+tardif</a></h2>
+    <p><code class="module"><a href="../mod/mod_headers.html">mod_headers</a></code> peut agir soir précocement, soit
+    tardivement au niveau de la requête. Le mode normal est le mode
+    tardif, lorsque les en-têtes de <em>requête</em> sont définis, immédiatement
+    avant l'exécution du générateur de contenu, et pour les en-têtes de
+    <em>réponse</em>, juste au moment où la réponse est envoyée sur le réseau.
+    Utilisez toujours le mode tardif sur un serveur en production.</p>
+
+    <p>Le mode précoce a été conçu à des fins d'aide aux tests et au
+    débogage pour les développeurs. Les directives définies en utilisant
+    le mot-clé <code>early</code> sont censées agir au tout début du
+    traitement de la requête. Cela signifie que l'on peut les utiliser
+    pour simuler différentes requêtes et définir des situations de test,
+    tout en gardant à l'esprit que les en-têtes peuvent être modifiés à
+    tout moment par d'autres modules avant que le réponse ne soit
+    générée.</p>
+
+    <p>Comme les directives précoces sont traitées avant que le
+    chemin de la requête ne soit parcouru, les en-têtes
+    précoces ne peuvent être définis que dans un contexte de serveur
+    principal ou de serveur virtuel. Les directives précoces ne peuvent
+    pas dépendre d'un chemin de requête, si bien qu'elles échoueront
+    dans des contextes tels que <code class="directive"><a href="../mod/core.html#directory">&lt;Directory&gt;</a></code> ou <code class="directive"><a href="../mod/core.html#location">&lt;Location&gt;</a></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="examples" id="examples">Exemples</a></h2>
+
+    <ol>
+      <li>
+        Copie tous les en-têtes de requête qui commencent par "TS" vers
+	les en-têtes de la réponse :
+
+        <pre class="prettyprint lang-config">Header echo ^TS</pre>
+
+      </li>
+
+      <li>
+        Ajoute à la réponse un en-tête, <code>mon-en-tête</code>, qui
+	contient un horodatage permettant de déterminer le moment où la
+	requête a été reçue, et le temps qui s'est écoulé jusqu'à ce que
+	la requête ait commencé à être servie. Cet en-tête peut être
+	utilisé par le client pour estimer la charge du serveur ou
+	isoler les goulets d'étranglement entre le client et le
+	serveur.
+
+        <pre class="prettyprint lang-config">Header set mon-en-tête "%D %t"</pre>
+
+
+        <p>le résultat est l'ajout à la réponse d'un en-tête du type :</p>
+
+        <div class="example"><p><code>
+          mon-en-tête: D=3775428 t=991424704447256
+        </code></p></div>
+      </li>
+
+      <li>
+        Dit Bonjour à Joe
+
+        <div class="example"><p><code>
+          Header set mon-en-tête "Bonjour Joe. Il a fallu %D microsecondes \<br />
+          à Apache pour servir cette requête."
+        </code></p></div>
+
+        <p>le résultat est l'ajout à la réponse d'un en-tête du type :</p>
+
+        <pre class="prettyprint lang-config">	Header set MyHeader "Bonjour Joe. Il a fallu D=3775428 microsecondes à Apache
+          pour servir cette requête."</pre>
+
+      </li>
+
+      <li>
+        Ajoute l'en-tête <code>mon-en-tête</code> à la réponse si et
+	seulement si l'en-tête <code>mon-en-tête-requête</code> est
+	présent dans la requête. Ceci peut s'avérer utile pour générer
+	des en-têtes de réponse "à la tête du client". Notez que cet
+	exemple nécessite les services du module
+	<code class="module"><a href="../mod/mod_setenvif.html">mod_setenvif</a></code>.
+
+        <pre class="prettyprint lang-config">SetEnvIf MyRequestHeader myvalue HAVE_MyRequestHeader
+Header set MyHeader "%D %t mytext" env=HAVE_MyRequestHeader</pre>
+
+
+        <p>Si l'en-tête <code>mon-en-tête-requête: mavaleur</code> est
+	présent dans la requête HTTP, la réponse contiendra un en-tête
+	du type :</p>
+
+        <div class="example"><p><code>
+          mon-en-tête: D=3775428 t=991424704447256 montexte
+        </code></p></div>
+      </li>
+
+      <li>
+        Permet à DAV de fonctionner avec Apache sur SSL (voir la <a href="http://svn.haxx.se/users/archive-2006-03/0549.shtml">description
+	du problème</a>) en remplaçant <var>https:</var> par
+	<var>http:</var> dans l'en-tête <var>Destination</var> :
+
+        <pre class="prettyprint lang-config">RequestHeader edit Destination ^https: http: early</pre>
+
+      </li>
+
+      <li>
+        Définit la valeur d'un même en-tête sous de multiples conditions
+	non exclusives, mais ne duplique pas une valeur déjà définie
+	dans l'en-tête qui en résulte. Si toutes les conditions
+	suivantes sont satisfaites pour une requête (en d'autres termes,
+	si les trois variables d'environnement <code>CGI</code>,
+	<code>NO_CACHE</code> et <code>NO_STORE</code> existent pour la
+	requête) :
+
+        <pre class="prettyprint lang-config">Header merge Cache-Control no-cache env=CGI
+Header merge Cache-Control no-cache env=NO_CACHE
+Header merge Cache-Control no-store env=NO_STORE</pre>
+
+
+        <p>alors, la réponse contiendra l'en-tête suivant :</p>
+
+        <div class="example"><p><code>
+          Cache-Control: no-cache, no-store
+        </code></p></div>
+
+        <p>Si <code>append</code> avait été utilisé à la place de
+	<code>merge</code>, la réponse aurait contenu l'en-tête suivant
+	:</p>
+
+        <div class="example"><p><code>
+          Cache-Control: no-cache, no-cache, no-store
+        </code></p></div>
+      </li>
+      <li>
+        Définit un cookie de test si et seulement si le client n'envoie
+	pas de cookie
+        <pre class="prettyprint lang-config">Header set Set-Cookie testcookie "expr=-z %{req:Cookie}"</pre>
+
+      </li>
+      <li>
+        Ajoute un en-tête de mise en cache pour les réponses avec un
+	code d'état HTTP de 200
+        <pre class="prettyprint lang-config">Header append Cache-Control s-maxage=600 "expr=%{REQUEST_STATUS} == 200"</pre>
+
+      </li>
+
+    </ol>
+</div>
 <div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
 <div class="directive-section"><h2><a name="header" id="header">Directive</a> <a name="Header" id="Header">Header</a></h2>
 <table class="directive">
@@ -438,173 +605,6 @@ version 2.4.10</td></tr>
     d'Apache.</p>
 
 </div>
-<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="order" id="order">Chronologie du traitement</a></h2>
-
-    <p>Les directives fournies par <code class="module"><a href="../mod/mod_headers.html">mod_headers</a></code> peuvent
-    s'insérer presque partout dans la configuration du serveur, et on
-    peut limiter leur portée en les plaçant dans des <a href="../sections.html">sections de configuration</a>.</p>
-
-    <p>La chronologie du traitement est importante et est affectée par
-    l'ordre d'apparition des directives dans le fichier de configuration
-    et par leur placement dans les <a href="../sections.html#mergin">sections de configuration</a>. Ainsi,
-    ces deux directives ont un effet différent si leur ordre est inversé
-    :</p>
-
-    <pre class="prettyprint lang-config">RequestHeader append MirrorID "mirror 12"
-RequestHeader unset MirrorID</pre>
-
-
-    <p>Dans cet ordre, l'en-tête <code>MirrorID</code> n'est pas défini.
-    Si l'ordre des directives était inversé, l'en-tête
-    <code>MirrorID</code> serait défini à "mirror 12".</p>
-</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
-<div class="section">
-<h2><a name="early" id="early">Traitement précoce et traitement
-tardif</a></h2>
-    <p><code class="module"><a href="../mod/mod_headers.html">mod_headers</a></code> peut agir soir précocement, soit
-    tardivement au niveau de la requête. Le mode normal est le mode
-    tardif, lorsque les en-têtes de <em>requête</em> sont définis, immédiatement
-    avant l'exécution du générateur de contenu, et pour les en-têtes de
-    <em>réponse</em>, juste au moment où la réponse est envoyée sur le réseau.
-    Utilisez toujours le mode tardif sur un serveur en production.</p>
-
-    <p>Le mode précoce a été conçu à des fins d'aide aux tests et au
-    débogage pour les développeurs. Les directives définies en utilisant
-    le mot-clé <code>early</code> sont censées agir au tout début du
-    traitement de la requête. Cela signifie que l'on peut les utiliser
-    pour simuler différentes requêtes et définir des situations de test,
-    tout en gardant à l'esprit que les en-têtes peuvent être modifiés à
-    tout moment par d'autres modules avant que le réponse ne soit
-    générée.</p>
-
-    <p>Comme les directives précoces sont traitées avant que le
-    chemin de la requête ne soit parcouru, les en-têtes
-    précoces ne peuvent être définis que dans un contexte de serveur
-    principal ou de serveur virtuel. Les directives précoces ne peuvent
-    pas dépendre d'un chemin de requête, si bien qu'elles échoueront
-    dans des contextes tels que <code class="directive"><a href="../mod/core.html#directory">&lt;Directory&gt;</a></code> ou <code class="directive"><a href="../mod/core.html#location">&lt;Location&gt;</a></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="examples" id="examples">Exemples</a></h2>
-
-    <ol>
-      <li>
-        Copie tous les en-têtes de requête qui commencent par "TS" vers
-	les en-têtes de la réponse :
-
-        <pre class="prettyprint lang-config">Header echo ^TS</pre>
-
-      </li>
-
-      <li>
-        Ajoute à la réponse un en-tête, <code>mon-en-tête</code>, qui
-	contient un horodatage permettant de déterminer le moment où la
-	requête a été reçue, et le temps qui s'est écoulé jusqu'à ce que
-	la requête ait commencé à être servie. Cet en-tête peut être
-	utilisé par le client pour estimer la charge du serveur ou
-	isoler les goulets d'étranglement entre le client et le
-	serveur.
-
-        <pre class="prettyprint lang-config">Header set mon-en-tête "%D %t"</pre>
-
-
-        <p>le résultat est l'ajout à la réponse d'un en-tête du type :</p>
-
-        <div class="example"><p><code>
-          mon-en-tête: D=3775428 t=991424704447256
-        </code></p></div>
-      </li>
-
-      <li>
-        Dit Bonjour à Joe
-
-        <div class="example"><p><code>
-          Header set mon-en-tête "Bonjour Joe. Il a fallu %D microsecondes \<br />
-          à Apache pour servir cette requête."
-        </code></p></div>
-
-        <p>le résultat est l'ajout à la réponse d'un en-tête du type :</p>
-
-        <pre class="prettyprint lang-config">	Header set MyHeader "Bonjour Joe. Il a fallu D=3775428 microsecondes à Apache
-          pour servir cette requête."</pre>
-
-      </li>
-
-      <li>
-        Ajoute l'en-tête <code>mon-en-tête</code> à la réponse si et
-	seulement si l'en-tête <code>mon-en-tête-requête</code> est
-	présent dans la requête. Ceci peut s'avérer utile pour générer
-	des en-têtes de réponse "à la tête du client". Notez que cet
-	exemple nécessite les services du module
-	<code class="module"><a href="../mod/mod_setenvif.html">mod_setenvif</a></code>.
-
-        <pre class="prettyprint lang-config">SetEnvIf MyRequestHeader myvalue HAVE_MyRequestHeader
-Header set MyHeader "%D %t mytext" env=HAVE_MyRequestHeader</pre>
-
-
-        <p>Si l'en-tête <code>mon-en-tête-requête: mavaleur</code> est
-	présent dans la requête HTTP, la réponse contiendra un en-tête
-	du type :</p>
-
-        <div class="example"><p><code>
-          mon-en-tête: D=3775428 t=991424704447256 montexte
-        </code></p></div>
-      </li>
-
-      <li>
-        Permet à DAV de fonctionner avec Apache sur SSL (voir la <a href="http://svn.haxx.se/users/archive-2006-03/0549.shtml">description
-	du problème</a>) en remplaçant <var>https:</var> par
-	<var>http:</var> dans l'en-tête <var>Destination</var> :
-
-        <pre class="prettyprint lang-config">RequestHeader edit Destination ^https: http: early</pre>
-
-      </li>
-
-      <li>
-        Définit la valeur d'un même en-tête sous de multiples conditions
-	non exclusives, mais ne duplique pas une valeur déjà définie
-	dans l'en-tête qui en résulte. Si toutes les conditions
-	suivantes sont satisfaites pour une requête (en d'autres termes,
-	si les trois variables d'environnement <code>CGI</code>,
-	<code>NO_CACHE</code> et <code>NO_STORE</code> existent pour la
-	requête) :
-
-        <pre class="prettyprint lang-config">Header merge Cache-Control no-cache env=CGI
-Header merge Cache-Control no-cache env=NO_CACHE
-Header merge Cache-Control no-store env=NO_STORE</pre>
-
-
-        <p>alors, la réponse contiendra l'en-tête suivant :</p>
-
-        <div class="example"><p><code>
-          Cache-Control: no-cache, no-store
-        </code></p></div>
-
-        <p>Si <code>append</code> avait été utilisé à la place de
-	<code>merge</code>, la réponse aurait contenu l'en-tête suivant
-	:</p>
-
-        <div class="example"><p><code>
-          Cache-Control: no-cache, no-cache, no-store
-        </code></p></div>
-      </li>
-      <li>
-        Définit un cookie de test si et seulement si le client n'envoie
-	pas de cookie
-        <pre class="prettyprint lang-config">Header set Set-Cookie testcookie "expr=-z %{req:Cookie}"</pre>
-
-      </li>
-      <li>
-        Ajoute un en-tête de mise en cache pour les réponses avec un
-	code d'état HTTP de 200
-        <pre class="prettyprint lang-config">Header append Cache-Control s-maxage=600 "expr=%{REQUEST_STATUS} == 200"</pre>
-
-      </li>
-
-    </ol>
-</div>
 </div>
 <div class="bottomlang">
 <p><span>Langues Disponibles: </span><a href="../en/mod/mod_headers.html" hreflang="en" rel="alternate" title="English">&nbsp;en&nbsp;</a> |



Mime
View raw message