You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by gr...@apache.org on 2017/01/26 20:02:26 UTC
svn commit: r1780462 [11/23] - /httpd/httpd/trunk/docs/manual/mod/
Added: httpd/httpd/trunk/docs/manual/mod/mod_proxy_ajp.html.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_proxy_ajp.html.fr?rev=1780462&view=auto
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_proxy_ajp.html.fr (added)
+++ httpd/httpd/trunk/docs/manual/mod/mod_proxy_ajp.html.fr Thu Jan 26 20:02:25 2017
@@ -0,0 +1,676 @@
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr"><head>
+<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type" />
+<!--
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ This file is generated from xml source: DO NOT EDIT
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ -->
+<title>mod_proxy_ajp - Serveur Apache HTTP Version 2.5</title>
+<link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
+<link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
+<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /><link rel="stylesheet" type="text/css" href="../style/css/prettify.css" />
+<script src="../style/scripts/prettify.min.js" type="text/javascript">
+</script>
+
+<link href="../images/favicon.ico" rel="shortcut icon" /></head>
+<body>
+<div id="page-header">
+<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/quickreference.html">Directives</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p>
+<p class="apache">Serveur Apache HTTP Version 2.5</p>
+<img alt="" src="../images/feather.png" /></div>
+<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
+<div id="path">
+<a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">Serveur HTTP</a> > <a href="http://httpd.apache.org/docs/">Documentation</a> > <a href="../">Version 2.5</a> > <a href="./">Modules</a></div>
+<div id="page-content">
+<div id="preamble"><h1>Module Apache mod_proxy_ajp</h1>
+<div class="toplang">
+<p><span>Langues Disponibles: </span><a href="../en/mod/mod_proxy_ajp.html" hreflang="en" rel="alternate" title="English"> en </a> |
+<a href="../fr/mod/mod_proxy_ajp.html" title="Fran�ais"> fr </a> |
+<a href="../ja/mod/mod_proxy_ajp.html" hreflang="ja" rel="alternate" title="Japanese"> ja </a></p>
+</div>
+<table class="module"><tr><th><a href="module-dict.html#Description">Description:</a></th><td>Module de support AJP pour
+<code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code></td></tr>
+<tr><th><a href="module-dict.html#Status">Statut:</a></th><td>Extension</td></tr>
+<tr><th><a href="module-dict.html#ModuleIdentifier">Identificateur�de�Module:</a></th><td>proxy_ajp_module</td></tr>
+<tr><th><a href="module-dict.html#SourceFile">Fichier�Source:</a></th><td>mod_proxy_ajp.c</td></tr></table>
+<h3>Sommaire</h3>
+
+ <p>Ce module n�cessite le chargement de <code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code>. Il fournit le support du <code>Protocole Apache
+ JServ version 1.3</code> (nomm� dans la suite de ce document
+ <em>AJP13</em>).</p>
+
+ <p>Pour �tre en mesure d'exploiter le protocole <code>AJP13</code>,
+ il est donc n�cessaire de charger les modules
+ <code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code> et <code class="module"><a href="../mod/mod_proxy_ajp.html">mod_proxy_ajp</a></code>.</p>
+
+ <div class="warning"><h3>Avertissement</h3>
+ <p>N'activez pas la fonctionnalit� de mandataire avant d'avoir <a href="mod_proxy.html#access">s�curis� votre serveur</a>. Les
+ serveurs mandataires ouverts sont dangereux non seulement pour
+ votre r�seau, mais aussi pour l'Internet au sens large. </p>
+ </div>
+</div>
+<div id="quickview"><h3>Sujets</h3>
+<ul id="topics">
+<li><img alt="" src="../images/down.gif" /> <a href="#usage">Utilisation</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#env">Variables d'environnement</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#overviewprotocol">Vue d'ensemble du protocole</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#basppacketstruct">Structure de base des paquets</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#rpacetstruct">Structure des paquets de
+requ�te</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#resppacketstruct">Structure du paquet de la
+r�ponse</a></li>
+</ul><h3 class="directives">Directives</h3>
+<p>Ce module ne fournit aucune directive.</p>
+<h3>Traitement des bugs</h3><ul class="seealso"><li><a href="https://www.apache.org/dist/httpd/CHANGES_2.4">Journal des modifications de httpd</a></li><li><a href="https://bz.apache.org/bugzilla/buglist.cgi?bug_status=__open__&list_id=144532&product=Apache%20httpd-2&query_format=specific&order=changeddate%20DESC%2Cpriority%2Cbug_severity&component=mod_proxy_ajp">Probl�mes connus</a></li><li><a href="https://bz.apache.org/bugzilla/enter_bug.cgi?product=Apache%20httpd-2&component=mod_proxy_ajp">Signaler un bug</a></li></ul><h3>Voir aussi</h3>
+<ul class="seealso">
+<li><code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code></li>
+<li><a href="../env.html">Documentation sur les variables
+d'environnement</a></li>
+<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="usage" id="usage">Utilisation</a></h2>
+ <p>Ce module permet de mandater en inverse un serveur d'application
+ d'arri�re-plan (comme Apache Tomcat) qui utilise le protocole AJP13.
+ Son utilisation est similaire � celle d'un mandataire inverse HTTP,
+ mais s'appuie sur le prefixe <code>ajp://</code> :</p>
+
+ <div class="example"><h3>Mandataire inverse simple</h3><pre class="prettyprint lang-config">ProxyPass "/app" "ajp://backend.example.com:8009/app"</pre>
+</div>
+
+ <p>On peut aussi configurer un r�partiteur de charge :</p>
+ <div class="example"><h3>Mandataire inverse avec r�partiteur de charge</h3><pre class="prettyprint lang-config"><Proxy balancer://cluster>
+ BalancerMember ajp://app1.example.com:8009 loadfactor=1
+ BalancerMember ajp://app2.example.com:8009 loadfactor=2
+ ProxySet lbmethod=bytraffic
+</Proxy>
+ProxyPass "/app" "balancer://cluster/app"</pre>
+</div>
+
+ <p>Notez qu'en g�n�ral, la directive <code class="directive"><a href="../mod/mod_proxy.html#proxypassreverse">ProxyPassReverse</a></code> n'est pas
+ n�cessaire. La requ�te AJP inclut l'en-t�te host original fourni
+ au mandataire, et le serveur d'application est sens� g�n�rer des
+ en-t�tes auto-r�f�ren�ants relatifs � cet h�te ; aucune r��criture
+ n'est donc n�cessaire.</p>
+
+ <p>La situation la plus courante dans laquelle la directive <code class="directive"><a href="../mod/mod_proxy.html#proxypassreverse">ProxyPassReverse</a></code> est n�cessaire se
+ rencontre lorsque le chemin de l'URL au niveau du mandataire est
+ diff�rente de celle du serveur d'arri�re-plan. Dans ce cas, un
+ en-t�te redirect peut �tre r��crit relativement � l'URL de l'h�te
+ original (et non du serveur d'arri�re-plan <code>ajp://</code> URL)
+ ; par exemple :</p>
+ <div class="example"><h3>R��criture d'un chemin mandat�</h3><pre class="prettyprint lang-config">ProxyPass "/apps/foo" "ajp://backend.example.com:8009/foo"
+ProxyPassReverse "/apps/foo" "http://www.example.com/foo"</pre>
+</div>
+ <p>Il est cependant pr�f�rable en g�n�ral de d�ployer l'application
+ sur le serveur d'arri�re-plan avec le m�me chemin que sur le
+ mandataire.
+ </p>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="env" id="env">Variables d'environnement</a></h2>
+ <p>Les variables d'environnement dont le nom poss�de le pr�fixe
+ <code>AJP_</code> sont transmises au serveur original en tant
+ qu'attributs de requ�te AJP (le pr�fixe AJP_ �tant supprim� du nom
+ de la cl�).</p>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="overviewprotocol" id="overviewprotocol">Vue d'ensemble du protocole</a></h2>
+ <p>Le protocole <code>AJP13</code> est orient� paquet. Le format
+ binaire a �t� pr�f�r�, probablement pour des raisons de
+ performances, au format texte pourtant plus lisible. Le serveur web
+ communique avec le conteneur de servlets sur une connexion TCP. Pour
+ diminuer la charge induite par le processus de cr�ation de socket,
+ le serveur web va tenter d'utiliser des connexions TCP persistantes
+ avec le conteneur de servlets, et de r�utiliser les connexions
+ pendant plusieurs cycles requ�tes/r�ponse.</p>
+ <p>Lorsqu'une connexion a �t� assign�e � une requ�te particuli�re,
+ elle ne sera utilis�e pour aucune autre jusqu'� ce que le cycle de
+ traitement de la requ�te se soit termin�. En d'autres termes, il n'y
+ a pas de multiplexage des requ�tes sur une connexion. Ceci se
+ traduit par un code beaucoup plus simple � chaque extr�mit� de la
+ connexion, un nombre plus important de connexions �tant cependant
+ ouvertes en m�me temps.</p>
+ <p>Lorsque le serveur web a ouvert une connexion vers le conteneur
+ de servlets, celle-ci peut se trouver dans l'un des �tats suivants
+ :</p>
+ <ul>
+ <li> Idle <br /> Aucune requ�te n'est trait�e sur cette
+ connexion. </li>
+ <li> Assigned <br /> La connexion fait l'objet d'un traitement de
+ requ�te.</li>
+ </ul>
+ <p>Lorsqu'une connexion est assign�e au traitement d'une requ�te
+ particuli�re, les informations de base de cette derni�re (comme les
+ en-t�tes HTTP, etc...) sont envoy�es sur la connexion sous une forme
+ tr�s condens�e (par exemple les cha�nes courantes sont cod�es sous
+ forme d'entiers). Vous trouverez des d�tails sur ce format plus
+ loin dans la structure des paquets de requ�te. Si la requ�te poss�de
+ un corps <code>(content-length > 0)</code>, il est envoy� dans un
+ paquet s�par� imm�diatement apr�s.</p>
+ <p>A ce moment, le conteneur est probablement pr�t � traiter la
+ requ�te. Au cours de ce traitement, il peut renvoyer les messages
+ suivants au serveur web :</p>
+ <ul>
+ <li>SEND_HEADERS <br />Renvoie un jeu d'en-t�tes au navigateur.</li>
+ <li>SEND_BODY_CHUNK <br />Renvoie un tron�on de corps de requ�te au
+ navigateur.
+ </li>
+ <li>GET_BODY_CHUNK <br />Re�oit un autre tron�on de donn�es de la
+ requ�te si elle n'a pas encore �t� transmise int�gralement. Ce type
+ de transmission est n�cessaire car les paquets poss�dent une taille
+ maximale fixe, et des quantit�s quelconques de donn�es peuvent �tre
+ contenues dans le corps de la requ�te (pour un chargement de
+ fichier, par exemple). Notez que cela n'a rien � voir avec le
+ transfert HTTP fractionn�.</li>
+ <li>END_RESPONSE <br /> Termine le cycle du traitement de la
+ requ�te.</li>
+ </ul>
+ <p>Chaque message est associ� � un paquet de donn�es format�
+ diff�remment. Voir plus loin les structures des paquets de r�ponses
+ pour plus de d�tails.</p>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="basppacketstruct" id="basppacketstruct">Structure de base des paquets</a></h2>
+ <p>Ce protocole h�rite en partie de XDR, mais il diff�re sur de
+ nombreux points (pas d'alignement sur 4 bits, par exemple).</p>
+ <p>AJP13 utilise les octets selon leur ordre d'arriv�e par le r�seau
+ pour tous les types de donn�es.</p>
+ <p>Le protocole comporte quatre types de donn�es : octets, bool�ens,
+ entiers et cha�nes de caract�res.</p>
+ <dl>
+ <dt><strong>Octet</strong></dt><dd>Un seul octet.</dd>
+ <dt><strong>Bool�en</strong></dt>
+ <dd>Un seul octet, <code>1 = vrai</code>, <code>0 = faux</code>.
+ L'utilisation d'autres valeurs non nulles (dans le style C) peut
+ fonctionner dans certains cas, mais pas dans certains autres..</dd>
+ <dt><strong>Entier</strong></dt>
+ <dd>Un nombre compris entre <code>0 et 2^16 (32768)</code>, stock�
+ sur 2 octets en d�butant par l'octet de poids forts.</dd>
+ <dt><strong>Cha�ne</strong></dt>
+ <dd>Une cha�ne de taille variable (longueur limit�e � 2^16). Elle
+ est cod�e comme suit : les deux premiers octets repr�sentent la
+ longueur de la cha�ne, les octets suivants constituent la cha�ne
+ proprement dite (y compris le '\0' final). Notez que la longueur
+ encod�e dans les deux premiers octets ne prend pas en compte le
+ '\0' final, de la m�me mani�re que <code>strlen</code>. Cela peut
+ pr�ter � confusion du point de vue de Java qui est surcharg� de
+ d�clarations d'autoincr�mentation �tranges destin�es � traiter
+ ces terminateurs. Je suppose que le but dans lequel cela a
+ �t� con�u ainsi �tait de permettre au code C d'�tre plus efficace
+ lors de la lecture de cha�nes en provenance du conteneur de
+ servlets -- avec le caract�re \0 final, le code C peut transmettre
+ des r�f�rences dans un seul tampon, sans avoir � effectuer de
+ copie. En l'absence du caract�re \0 final, le code C doit
+ effectuer une copie afin de pouvoir tenir compte de sa notion de
+ cha�ne.</dd>
+ </dl>
+
+ <h3>Taille du paquet</h3>
+ <p>Selon la majorit� du code, la taille maximale du paquet est de
+ <code>8 * 1024 bytes (8K)</code>. La taille r�elle du paquet est
+ encod�e dans l'en-t�te.</p>
+
+ <h3>En-t�tes de paquet</h3>
+ <p>Les paquets envoy�s par le serveur vers le conteneur commencent
+ par <code>0x1234</code>. Les paquets envoy�s par le conteneur vers
+ le serveur commencent par <code>AB</code> (c'est � dire le code
+ ASCII de A suivi du code ASCII de B). Ensuite, vient un entier (cod�
+ comme ci-dessus) repr�sentant la longueur des donn�es transmises.
+ Bien que ceci puisse faire croire que la taille maximale des donn�es
+ est de 2^16, le code d�finit en fait ce maximum � 8K.</p>
+ <table>
+
+ <tr>
+ <th colspan="6"><em>Format du paquet (Serveur->Conteneur)</em></th>
+ </tr>
+ <tr>
+ <th>Octet</th>
+ <td>0</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ <td>4...(n+3)</td>
+ </tr>
+ <tr>
+ <th>Contenu</th>
+ <td>0x12</td>
+ <td>0x34</td>
+ <td colspan="2">Taille des donn�es (n)</td>
+ <td>Data</td>
+ </tr>
+ </table>
+ <table>
+
+ <tr>
+ <th colspan="6"><em>Format du paquet
+ (Conteneur->Serveur)</em></th>
+ </tr>
+ <tr>
+ <th>Octet</th>
+ <td>0</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ <td>4...(n+3)</td>
+ </tr>
+ <tr>
+ <th>Contenu</th>
+ <td>A</td>
+ <td>B</td>
+ <td colspan="2">Taille des donn�es (n)</td>
+ <td>Data</td>
+ </tr>
+ </table>
+ <p>Pour la plupart des paquets, le premier octet de la charge utile
+ encode le type de message, � l'exception des paquets contenant un
+ corps de requ�te envoy�s du serveur vers le conteneur -- ils
+ comportent un en-t�te standard (<code>0x1234</code> suivi de la taille
+ du paquet), mais celui-ci n'est suivi d'aucun pr�fixe.</p>
+ <p>Le serveur web peut envoyer les messages suivants au conteneur
+ de servlets :</p>
+ <table>
+
+ <tr>
+ <td>Code</td>
+ <td>Type de paquet</td>
+ <td>Signification</td>
+ </tr>
+ <tr>
+ <td>2</td>
+ <td>Fait suivre la requ�te</td>
+ <td>D�bute le cycle de traitement de la requ�te avec les donn�es
+ qui suivent.</td>
+ </tr>
+ <tr>
+ <td>7</td>
+ <td>Arr�t</td>
+ <td>Le serveur web demande au conteneur de s'arr�ter.</td>
+ </tr>
+ <tr>
+ <td>8</td>
+ <td>Ping</td>
+ <td>Le serveur web demande au conteneur de prendre le contr�le
+ (phase de connexion s�curis�e).</td>
+ </tr>
+ <tr>
+ <td>10</td>
+ <td>CPing</td>
+ <td>Le serveur web demande au conteneur de r�pondre rapidement
+ avec un CPong.
+ </td>
+ </tr>
+ <tr>
+ <td>none</td>
+ <td>Donn�es</td>
+ <td>Taille (2 octets) et les donn�es correspondantes.</td>
+ </tr>
+ </table>
+ <p>� des fins de s�curit�, le conteneur n'effectuera r�ellement son
+ <code>Arr�t</code> que si la demande provient de la machine par
+ laquelle il est h�berg�.</p>
+ <p>Le premier paquet <code>Donn�es</code> est envoy� imm�diatement
+ apr�s le paquet <code>Faire suivre la requ�te</code> par le serveur
+ web.</p>
+ <p>Le conteneur de servlets peut envoyer les types de messages
+ suivants au serveur web :</p>
+ <table>
+
+ <tr>
+ <td>Code</td>
+ <td>Type de paquet</td>
+ <td>Signification</td>
+ </tr>
+ <tr>
+ <td>3</td>
+ <td>Envoi d'un tron�on de corps</td>
+ <td>Envoi d'un tron�on de corps depuis le conteneur de servlets
+ vers le serveur web (et probablement vers le navigateur).</td>
+ </tr>
+ <tr>
+ <td>4</td>
+ <td>Envoie les en-t�tes</td>
+ <td>Envoi des en-t�tes de r�ponse depuis le conteneur de
+ servlets vers le serveur web (et probablement vers le
+ navigateur).</td>
+ </tr>
+ <tr>
+ <td>5</td>
+ <td>Fin de la r�ponse</td>
+ <td>Marque la fin de la r�ponse (et par cons�quent du cycle de
+ traitement de la requ�te).
+ </td>
+ </tr>
+ <tr>
+ <td>6</td>
+ <td>R�ception du tron�on de corps suivant</td>
+ <td>R�ception de la suite des donn�es de la requ�te si elles
+ n'ont pas encore �t� enti�rement transmises.</td>
+ </tr>
+ <tr>
+ <td>9</td>
+ <td>R�ponse CPong</td>
+ <td>La r�ponse � une requ�te CPing</td>
+ </tr>
+ </table>
+ <p>Chacun des messages ci-dessus poss�de une structure interne
+ diff�rente dont vous trouverez les d�tails ci-dessous.</p>
+
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="rpacetstruct" id="rpacetstruct">Structure des paquets de
+requ�te</a></h2>
+ <p>Pour les messages de type <em>Faire suivre la requ�te</em> depuis
+ le serveur vers le conteneur :</p>
+ <div class="example"><pre>AJP13_FORWARD_REQUEST :=
+ prefix_code (byte) 0x02 = JK_AJP13_FORWARD_REQUEST
+ method (byte)
+ protocol (string)
+ req_uri (string)
+ remote_addr (string)
+ remote_host (string)
+ server_name (string)
+ server_port (integer)
+ is_ssl (boolean)
+ num_headers (integer)
+ request_headers *(req_header_name req_header_value)
+ attributes *(attribut_name attribute_value)
+ request_terminator (byte) OxFF</pre></div>
+ <p>Les <code>request_headers</code> poss�dent la structure suivante
+ :
+ </p><div class="example"><pre>req_header_name :=
+ sc_req_header_name | (string) [voir ci-dessous pour la mani�re dont
+ ceci est interpr�t�]
+
+sc_req_header_name := 0xA0xx (integer)
+
+req_header_value := (string)</pre></div>
+ <p>Les <code>attributes</code> sont optionnels et poss�dent la
+ structure suivante :</p>
+ <div class="example"><pre>attribute_name := sc_a_name | (sc_a_req_attribute string)
+
+attribute_value := (string)</pre></div>
+ <p>Un des en-t�tes les plus importants est
+ <code>content-length</code>, car il indique si le conteneur doit ou
+ non attendre un autre paquet imm�diatement.</p>
+ <h3>Description d�taill�e de la requ�te que le serveur
+ fait suivre vers le conteneur
+ </h3>
+ <h3>Pr�fixe de la requ�te</h3>
+ <p>Pour toutes les requ�tes, ce pr�fixe est 2. Voir ci-dessus pour
+ les d�tails des autres codes de pr�fixes.</p>
+
+ <h3>M�thode</h3>
+ <p>La m�thode HTTP, encod�e sous la forme d'un seul octet :</p>
+ <table>
+ <tr><td>Nom commande</td><td>Code</td></tr>
+ <tr><td>OPTIONS</td><td>1</td></tr>
+ <tr><td>GET</td><td>2</td></tr>
+ <tr><td>HEAD</td><td>3</td></tr>
+ <tr><td>POST</td><td>4</td></tr>
+ <tr><td>PUT</td><td>5</td></tr>
+ <tr><td>DELETE</td><td>6</td></tr>
+ <tr><td>TRACE</td><td>7</td></tr>
+ <tr><td>PROPFIND</td><td>8</td></tr>
+ <tr><td>PROPPATCH</td><td>9</td></tr>
+ <tr><td>MKCOL</td><td>10</td></tr>
+ <tr><td>COPY</td><td>11</td></tr>
+ <tr><td>MOVE</td><td>12</td></tr>
+ <tr><td>LOCK</td><td>13</td></tr>
+ <tr><td>UNLOCK</td><td>14</td></tr>
+ <tr><td>ACL</td><td>15</td></tr>
+ <tr><td>REPORT</td><td>16</td></tr>
+ <tr><td>VERSION-CONTROL</td><td>17</td></tr>
+ <tr><td>CHECKIN</td><td>18</td></tr>
+ <tr><td>CHECKOUT</td><td>19</td></tr>
+ <tr><td>UNCHECKOUT</td><td>20</td></tr>
+ <tr><td>SEARCH</td><td>21</td></tr>
+ <tr><td>MKWORKSPACE</td><td>22</td></tr>
+ <tr><td>UPDATE</td><td>23</td></tr>
+ <tr><td>LABEL</td><td>24</td></tr>
+ <tr><td>MERGE</td><td>25</td></tr>
+ <tr><td>BASELINE_CONTROL</td><td>26</td></tr>
+ <tr><td>MKACTIVITY</td><td>27</td></tr>
+ </table>
+ <p>Les versions futures d'ajp13 pourront transmettre des m�thodes
+ suppl�mentaires, m�me si elles ne font pas partie de cette
+ liste.</p>
+
+ <h3>protocol, req_uri, remote_addr, remote_host, server_name,
+ server_port, is_ssl</h3>
+ <p>Les significations de ces �l�ments sont triviales. Ils sont tous
+ obligatoires et seront envoy�s avec chaque requ�te.</p>
+
+ <h3>En-t�tes</h3>
+ <p>La structure de <code>request_headers</code> est la suivante
+ : tout d'abord, le nombre d'en-t�tes <code>num_headers</code> est
+ encod�, suivi d'une liste de paires nom d'en-t�te
+ <code>req_header_name</code> / valeur <code>req_header_value</code>.
+ Les noms d'en-t�tes courants sont cod�s sous forme d'entiers afin de
+ gagner de la place. Si le nom d'en-t�te ne fait partie de la liste
+ des en-t�tes courants, il est encod� normalement (une cha�ne de
+ caract�res pr�fix�e par la taille). La liste des en-t�tes courants
+ <code>sc_req_header_name</code> avec leurs codes se pr�sente comme
+ suit (il sont tous sensibles � la casse) :</p>
+ <table>
+ <tr><td>Nom</td><td>Valeur du code</td><td>Nom du code</td></tr>
+ <tr><td>accept</td><td>0xA001</td><td>SC_REQ_ACCEPT</td></tr>
+ <tr><td>accept-charset</td><td>0xA002</td><td>SC_REQ_ACCEPT_CHARSET
+ </td></tr>
+ <tr><td>accept-encoding</td><td>0xA003</td><td>SC_REQ_ACCEPT_ENCODING
+ </td></tr>
+ <tr><td>accept-language</td><td>0xA004</td><td>SC_REQ_ACCEPT_LANGUAGE
+ </td></tr>
+ <tr><td>authorization</td><td>0xA005</td><td>SC_REQ_AUTHORIZATION</td>
+ </tr>
+ <tr><td>connection</td><td>0xA006</td><td>SC_REQ_CONNECTION</td></tr>
+ <tr><td>content-type</td><td>0xA007</td><td>SC_REQ_CONTENT_TYPE</td>
+ </tr>
+ <tr><td>content-length</td><td>0xA008</td><td>SC_REQ_CONTENT_LENGTH</td>
+ </tr>
+ <tr><td>cookie</td><td>0xA009</td><td>SC_REQ_COOKIE</td></tr>
+ <tr><td>cookie2</td><td>0xA00A</td><td>SC_REQ_COOKIE2</td></tr>
+ <tr><td>host</td><td>0xA00B</td><td>SC_REQ_HOST</td></tr>
+ <tr><td>pragma</td><td>0xA00C</td><td>SC_REQ_PRAGMA</td></tr>
+ <tr><td>referer</td><td>0xA00D</td><td>SC_REQ_REFERER</td></tr>
+ <tr><td>user-agent</td><td>0xA00E</td><td>SC_REQ_USER_AGENT</td></tr>
+ </table>
+ <p>Le code Java qui lit ceci extrait l'entier repr�sent� par les
+ deux premiers octets, et si le premier octet est
+ <code>'0xA0'</code>, il utilise l'entier repr�sent� par le deuxi�me
+ octet comme index d'un tableau de noms d'en-t�tes. Si le premier
+ octet n'est pas <code>0xA0</code>, l'entier repr�sent� par les deux
+ octets est consid�r� comme la longueur d'une cha�ne qui est alors
+ lue.</p>
+ <p>Ceci ne peut fonctionner que si aucun nom d'en-t�te ne poss�de
+ une taille sup�rieure � <code>0x9FFF (==0xA000 - 1)</code>, ce qui
+ est vraisemblable, bien qu'un peu arbitraire.</p>
+ <div class="note"><h3>Note:</h3>
+ L'en-t�te <code>content-length</code> est extr�mement important.
+ S'il est pr�sent et non nul, le conteneur consid�re que la requ�te
+ poss�de un corps (une requ�te POST, par exemple), et lit
+ imm�diatement le paquet suivant dans le flux d'entr�e pour extraire
+ ce corps.
+ </div>
+
+ <h3>Attributs</h3>
+ <p>Les attributs pr�fix�s par <code>?</code> (par exemple
+ <code>?context</code>) sont tous optionnels. Chacun d'eux est
+ repr�sent� par un octet correspondant au type de l'attribut et par
+ sa valeur (cha�ne ou entier). Ils peuvent �tre envoy�s dans un ordre
+ quelconque (bien que le code C les envoie dans l'ordre ci-dessous).
+ Un code de terminaison sp�cial est envoy� pour signaler la fin de la
+ liste des attributs optionnels. La liste des codes est la suivante
+ :</p>
+ <table>
+ <tr><td>Information</td><td>Valeur code</td><td>Type de valeur</td><td>Note</td></tr>
+ <tr><td>?context</td><td>0x01</td><td>-</td><td>Non impl�ment�
+ actuellement
+ </td></tr>
+ <tr><td>?servlet_path</td><td>0x02</td><td>-</td><td>Non impl�ment�
+ actuellement
+ </td></tr>
+ <tr><td>?remote_user</td><td>0x03</td><td>String</td><td /></tr>
+ <tr><td>?auth_type</td><td>0x04</td><td>String</td><td /></tr>
+ <tr><td>?query_string</td><td>0x05</td><td>String</td><td /></tr>
+ <tr><td>?jvm_route</td><td>0x06</td><td>String</td><td /></tr>
+ <tr><td>?ssl_cert</td><td>0x07</td><td>String</td><td /></tr>
+ <tr><td>?ssl_cipher</td><td>0x08</td><td>String</td><td /></tr>
+ <tr><td>?ssl_session</td><td>0x09</td><td>String</td><td /></tr>
+ <tr><td>?req_attribute</td><td>0x0A</td><td>String</td><td>Nom (le
+ nom de l'attribut vient ensuite)</td></tr>
+ <tr><td>?ssl_key_size</td><td>0x0B</td><td>Integer</td><td /></tr>
+ <tr><td>are_done</td><td>0xFF</td><td>-</td><td>request_terminator</td></tr>
+ </table>
+ <p><code>context</code> et <code>servlet_path</code> ne sont pas
+ d�finis actuellement par le code C, et la majorit� du code Java
+ ignore compl�tement ce qui est envoy� par l'interm�diaire de ces
+ champs (il va m�me parfois s'interrompre si une cha�ne est
+ envoy�e apr�s un de ces codes). Je ne sais pas si c'est une bogue ou
+ une fonctionnalit� non impl�ment�e, ou tout simplement du code
+ obsol�te, mais en tout cas, il n'est pris en charge par aucune des
+ deux extr�mit�s de la connexion.</p>
+ <p><code>remote_user</code> et <code>auth_type</code> concernent
+ probablement l'authentification au niveau HTTP, et contiennent le
+ nom de l'utilisateur distant ainsi que le type d'authentification
+ utilis�e pour �tablir son identit� (� savoir Basic, Digest).</p>
+ <p><code>query_string</code>, <code>ssl_cert</code>,
+ <code>ssl_cipher</code> et <code>ssl_session</code> contiennent les
+ �l�ments HTTP et HTTPS correspondants.</p>
+ <p><code>jvm_route</code> est utilis� dans le cadre des sessions
+ persistantes, en associant une session utilisateur � une instance
+ Tomcat particuli�re en pr�sence de plusieurs r�partiteurs de
+ charge.</p>
+ <p>Au del� de cette liste de base, tout autre attribut
+ suppl�mentaire peut �tre envoy� via le code
+ <code>req_attribute</code> <code>0x0A</code>. Une paire de cha�nes
+ repr�sentant le nom et la valeur de l'attribut est envoy�e
+ imm�diatement apr�s chaque instance de ce code. Les variables
+ d'environnement sont transmises par cette m�thode.</p>
+ <p>Enfin, lorsque tous les attributs ont �t� transmis, le
+ terminateur d'attributs, <code>0xFF</code>, est envoy�. Ce dernier
+ indique � la fois la fin de la liste d'attributs et la fin du paquet
+ de la requ�te</p>
+
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="resppacketstruct" id="resppacketstruct">Structure du paquet de la
+r�ponse</a></h2>
+ <p>Pour les messages que le conteneur peut renvoyer au
+ serveur.</p>
+ <div class="example"><pre>AJP13_SEND_BODY_CHUNK :=
+ prefix_code 3
+ chunk_length (integer)
+ chunk *(byte)
+ chunk_terminator (byte) Ox00
+
+
+AJP13_SEND_HEADERS :=
+ prefix_code 4
+ http_status_code (integer)
+ http_status_msg (string)
+ num_headers (integer)
+ response_headers *(res_header_name header_value)
+
+res_header_name :=
+ sc_res_header_name | (string) [voir ci-dessous pour la mani�re
+ dont ceci est interpr�t�]
+
+sc_res_header_name := 0xA0 (byte)
+
+header_value := (string)
+
+AJP13_END_RESPONSE :=
+ prefix_code 5
+ reuse (boolean)
+
+
+AJP13_GET_BODY_CHUNK :=
+ prefix_code 6
+ requested_length (integer)</pre></div>
+ <h3>D�tails:</h3>
+ <h3>Envoi d'un tron�on de corps</h3>
+ <p>Le tron�on se compose essentiellement de donn�es binaires et est
+ renvoy� directement au navigateur.</p>
+
+ <h3>Envoi des en-t�tes</h3>
+ <p>Les code et message d'�tat correspondent aux code et message HTTP
+ habituels (par exemple <code>200</code> et <code>OK</code>). Les
+ noms d'en-t�tes de r�ponses sont cod�s de la m�me fa�on que les noms
+ d'en-t�tes de requ�tes. Voir ci-dessus le codage des en-t�tes pour
+ plus de d�tails � propos de la mani�re dont les codes se distinguent
+ des cha�nes.<br />
+ Les codes des en-t�tes courants sont ::</p>
+ <table>
+ <tr><td>Nom</td><td>Valeur code</td></tr>
+ <tr><td>Content-Type</td><td>0xA001</td></tr>
+ <tr><td>Content-Language</td><td>0xA002</td></tr>
+ <tr><td>Content-Length</td><td>0xA003</td></tr>
+ <tr><td>Date</td><td>0xA004</td></tr>
+ <tr><td>Last-Modified</td><td>0xA005</td></tr>
+ <tr><td>Location</td><td>0xA006</td></tr>
+ <tr><td>Set-Cookie</td><td>0xA007</td></tr>
+ <tr><td>Set-Cookie2</td><td>0xA008</td></tr>
+ <tr><td>Servlet-Engine</td><td>0xA009</td></tr>
+ <tr><td>Status</td><td>0xA00A</td></tr>
+ <tr><td>WWW-Authenticate</td><td>0xA00B</td></tr>
+ </table>
+ <p>La valeur de l'en-t�te est cod�e imm�diatement apr�s le code ou
+ la cha�ne du nom d'en-t�te.</p>
+
+ <h3>Fin de la r�ponse</h3>
+ <p>Signale la fin de ce cycle de traitement de requ�te. Si le
+ drapeau <code>reuse</code> est � true <code>(toute valeur autre que
+ 0 en langage C pur)</code>, cette
+ connexion TCP peut �tre r�utilis�e pour traiter de nouvelles
+ requ�tes entrantes. Si <code>reuse</code> est � false
+ (==0), la connexion sera ferm�e.</p>
+
+ <h3>R�ception d'un tron�on de corps</h3>
+ <p>Le conteneur r�clame la suite des donn�es de la requ�te (dans le
+ cas o� la taille du corps �tait trop importante pour pouvoir �tre
+ contenue dans le premier paquet envoy�, o� lorsque la requ�te est
+ fractionn�e). Le serveur va alors envoyer un paquet contenant une
+ quantit� de donn�es correspondant au minimum de la
+ <code>request_length</code>, la taille maximale de corps envoy�e
+ <code>(8186 (8 Koctets - 6))</code>, et le nombre r�el d'octets
+ restants � envoyer pour ce corps de requ�te.<br />
+ S'il ne reste plus de donn�es � transmettre pour ce corps de requ�te
+ (c'est � dire si le conteneur de servlets tente de lire au del� de
+ la fin du corps), le serveur va renvoyer un paquet <em>vide</em>
+ dont la charge utile est de longueur 0 et se pr�sentant sous la
+ forme <code>(0x12,0x34,0x00,0x00)</code>.</p>
+
+</div>
+</div>
+<div class="bottomlang">
+<p><span>Langues Disponibles: </span><a href="../en/mod/mod_proxy_ajp.html" hreflang="en" rel="alternate" title="English"> en </a> |
+<a href="../fr/mod/mod_proxy_ajp.html" title="Fran�ais"> fr </a> |
+<a href="../ja/mod/mod_proxy_ajp.html" hreflang="ja" rel="alternate" title="Japanese"> ja </a></p>
+</div><div class="top"><a href="#page-header"><img src="../images/up.gif" alt="top" /></a></div><div class="section"><h2><a id="comments_section" name="comments_section">Commentaires</a></h2><div class="warning"><strong>Notice:</strong><br />This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our <a href="http://httpd.apache.org/lists.html">mailing lists</a>.</div>
+<script type="text/javascript"><!--//--><![CDATA[//><!--
+var comments_shortname = 'httpd';
+var comments_identifier = 'http://httpd.apache.org/docs/trunk/mod/mod_proxy_ajp.html';
+(function(w, d) {
+ if (w.location.hostname.toLowerCase() == "httpd.apache.org") {
+ d.write('<div id="comments_thread"><\/div>');
+ var s = d.createElement('script');
+ s.type = 'text/javascript';
+ s.async = true;
+ s.src = 'https://comments.apache.org/show_comments.lua?site=' + comments_shortname + '&page=' + comments_identifier;
+ (d.getElementsByTagName('head')[0] || d.getElementsByTagName('body')[0]).appendChild(s);
+ }
+ else {
+ d.write('<div id="comments_thread">Comments are disabled for this page at the moment.<\/div>');
+ }
+})(window, document);
+//--><!]]></script></div><div id="footer">
+<p class="apache">Copyright 2017 The Apache Software Foundation.<br />Autoris� sous <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
+<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/quickreference.html">Directives</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p></div><script type="text/javascript"><!--//--><![CDATA[//><!--
+if (typeof(prettyPrint) !== 'undefined') {
+ prettyPrint();
+}
+//--><!]]></script>
+</body></html>
\ No newline at end of file
Added: httpd/httpd/trunk/docs/manual/mod/mod_proxy_ajp.xml.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_proxy_ajp.xml.fr?rev=1780462&view=auto
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_proxy_ajp.xml.fr (added)
+++ httpd/httpd/trunk/docs/manual/mod/mod_proxy_ajp.xml.fr [utf-8] Thu Jan 26 20:02:25 2017
@@ -0,0 +1,650 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
+<!-- English Revision: 1673945 -->
+<!-- French translation : Lucien GENTIS -->
+<!-- Reviewed by : Vincent Deffontaines -->
+
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<modulesynopsis metafile="mod_proxy_ajp.xml.meta">
+
+<name>mod_proxy_ajp</name>
+<description>Module de support AJP pour
+<module>mod_proxy</module></description>
+<status>Extension</status>
+<sourcefile>mod_proxy_ajp.c</sourcefile>
+<identifier>proxy_ajp_module</identifier>
+
+<summary>
+ <p>Ce module n�cessite le chargement de <module
+ >mod_proxy</module>. Il fournit le support du <code>Protocole Apache
+ JServ version 1.3</code> (nomm� dans la suite de ce document
+ <em>AJP13</em>).</p>
+
+ <p>Pour �tre en mesure d'exploiter le protocole <code>AJP13</code>,
+ il est donc n�cessaire de charger les modules
+ <module>mod_proxy</module> et <module>mod_proxy_ajp</module>.</p>
+
+ <note type="warning"><title>Avertissement</title>
+ <p>N'activez pas la fonctionnalit� de mandataire avant d'avoir <a
+ href="mod_proxy.html#access">s�curis� votre serveur</a>. Les
+ serveurs mandataires ouverts sont dangereux non seulement pour
+ votre r�seau, mais aussi pour l'Internet au sens large. </p>
+ </note>
+</summary>
+
+<seealso><module>mod_proxy</module></seealso>
+<seealso><a href="../env.html">Documentation sur les variables
+d'environnement</a></seealso>
+
+<section id="usage"><title>Utilisation</title>
+ <p>Ce module permet de mandater en inverse un serveur d'application
+ d'arri�re-plan (comme Apache Tomcat) qui utilise le protocole AJP13.
+ Son utilisation est similaire � celle d'un mandataire inverse HTTP,
+ mais s'appuie sur le prefixe <code>ajp://</code> :</p>
+
+ <example><title>Mandataire inverse simple</title>
+ <highlight language="config">
+ ProxyPass "/app" "ajp://backend.example.com:8009/app"
+ </highlight>
+ </example>
+
+ <p>On peut aussi configurer un r�partiteur de charge :</p>
+ <example><title>Mandataire inverse avec r�partiteur de charge</title>
+ <highlight language="config">
+<Proxy balancer://cluster>
+ BalancerMember ajp://app1.example.com:8009 loadfactor=1
+ BalancerMember ajp://app2.example.com:8009 loadfactor=2
+ ProxySet lbmethod=bytraffic
+</Proxy>
+ProxyPass "/app" "balancer://cluster/app"
+ </highlight>
+ </example>
+
+ <p>Notez qu'en g�n�ral, la directive <directive
+ module="mod_proxy">ProxyPassReverse</directive> n'est pas
+ n�cessaire. La requ�te AJP inclut l'en-t�te host original fourni
+ au mandataire, et le serveur d'application est sens� g�n�rer des
+ en-t�tes auto-r�f�ren�ants relatifs � cet h�te ; aucune r��criture
+ n'est donc n�cessaire.</p>
+
+ <p>La situation la plus courante dans laquelle la directive <directive
+ module="mod_proxy">ProxyPassReverse</directive> est n�cessaire se
+ rencontre lorsque le chemin de l'URL au niveau du mandataire est
+ diff�rente de celle du serveur d'arri�re-plan. Dans ce cas, un
+ en-t�te redirect peut �tre r��crit relativement � l'URL de l'h�te
+ original (et non du serveur d'arri�re-plan <code>ajp://</code> URL)
+ ; par exemple :</p>
+ <example><title>R��criture d'un chemin mandat�</title>
+ <highlight language="config">
+ProxyPass "/apps/foo" "ajp://backend.example.com:8009/foo"
+ProxyPassReverse "/apps/foo" "http://www.example.com/foo"
+ </highlight>
+ </example>
+ <p>Il est cependant pr�f�rable en g�n�ral de d�ployer l'application
+ sur le serveur d'arri�re-plan avec le m�me chemin que sur le
+ mandataire.
+ </p>
+</section>
+
+<section id="env"><title>Variables d'environnement</title>
+ <p>Les variables d'environnement dont le nom poss�de le pr�fixe
+ <code>AJP_</code> sont transmises au serveur original en tant
+ qu'attributs de requ�te AJP (le pr�fixe AJP_ �tant supprim� du nom
+ de la cl�).</p>
+</section>
+
+<section id="overviewprotocol"><title>Vue d'ensemble du protocole</title>
+ <p>Le protocole <code>AJP13</code> est orient� paquet. Le format
+ binaire a �t� pr�f�r�, probablement pour des raisons de
+ performances, au format texte pourtant plus lisible. Le serveur web
+ communique avec le conteneur de servlets sur une connexion TCP. Pour
+ diminuer la charge induite par le processus de cr�ation de socket,
+ le serveur web va tenter d'utiliser des connexions TCP persistantes
+ avec le conteneur de servlets, et de r�utiliser les connexions
+ pendant plusieurs cycles requ�tes/r�ponse.</p>
+ <p>Lorsqu'une connexion a �t� assign�e � une requ�te particuli�re,
+ elle ne sera utilis�e pour aucune autre jusqu'� ce que le cycle de
+ traitement de la requ�te se soit termin�. En d'autres termes, il n'y
+ a pas de multiplexage des requ�tes sur une connexion. Ceci se
+ traduit par un code beaucoup plus simple � chaque extr�mit� de la
+ connexion, un nombre plus important de connexions �tant cependant
+ ouvertes en m�me temps.</p>
+ <p>Lorsque le serveur web a ouvert une connexion vers le conteneur
+ de servlets, celle-ci peut se trouver dans l'un des �tats suivants
+ :</p>
+ <ul>
+ <li> Idle <br/> Aucune requ�te n'est trait�e sur cette
+ connexion. </li>
+ <li> Assigned <br/> La connexion fait l'objet d'un traitement de
+ requ�te.</li>
+ </ul>
+ <p>Lorsqu'une connexion est assign�e au traitement d'une requ�te
+ particuli�re, les informations de base de cette derni�re (comme les
+ en-t�tes HTTP, etc...) sont envoy�es sur la connexion sous une forme
+ tr�s condens�e (par exemple les cha�nes courantes sont cod�es sous
+ forme d'entiers). Vous trouverez des d�tails sur ce format plus
+ loin dans la structure des paquets de requ�te. Si la requ�te poss�de
+ un corps <code>(content-length > 0)</code>, il est envoy� dans un
+ paquet s�par� imm�diatement apr�s.</p>
+ <p>A ce moment, le conteneur est probablement pr�t � traiter la
+ requ�te. Au cours de ce traitement, il peut renvoyer les messages
+ suivants au serveur web :</p>
+ <ul>
+ <li>SEND_HEADERS <br/>Renvoie un jeu d'en-t�tes au navigateur.</li>
+ <li>SEND_BODY_CHUNK <br/>Renvoie un tron�on de corps de requ�te au
+ navigateur.
+ </li>
+ <li>GET_BODY_CHUNK <br/>Re�oit un autre tron�on de donn�es de la
+ requ�te si elle n'a pas encore �t� transmise int�gralement. Ce type
+ de transmission est n�cessaire car les paquets poss�dent une taille
+ maximale fixe, et des quantit�s quelconques de donn�es peuvent �tre
+ contenues dans le corps de la requ�te (pour un chargement de
+ fichier, par exemple). Notez que cela n'a rien � voir avec le
+ transfert HTTP fractionn�.</li>
+ <li>END_RESPONSE <br/> Termine le cycle du traitement de la
+ requ�te.</li>
+ </ul>
+ <p>Chaque message est associ� � un paquet de donn�es format�
+ diff�remment. Voir plus loin les structures des paquets de r�ponses
+ pour plus de d�tails.</p>
+</section>
+
+<section id="basppacketstruct"><title>Structure de base des paquets</title>
+ <p>Ce protocole h�rite en partie de XDR, mais il diff�re sur de
+ nombreux points (pas d'alignement sur 4 bits, par exemple).</p>
+ <p>AJP13 utilise les octets selon leur ordre d'arriv�e par le r�seau
+ pour tous les types de donn�es.</p>
+ <p>Le protocole comporte quatre types de donn�es : octets, bool�ens,
+ entiers et cha�nes de caract�res.</p>
+ <dl>
+ <dt><strong>Octet</strong></dt><dd>Un seul octet.</dd>
+ <dt><strong>Bool�en</strong></dt>
+ <dd>Un seul octet, <code>1 = vrai</code>, <code>0 = faux</code>.
+ L'utilisation d'autres valeurs non nulles (dans le style C) peut
+ fonctionner dans certains cas, mais pas dans certains autres..</dd>
+ <dt><strong>Entier</strong></dt>
+ <dd>Un nombre compris entre <code>0 et 2^16 (32768)</code>, stock�
+ sur 2 octets en d�butant par l'octet de poids forts.</dd>
+ <dt><strong>Cha�ne</strong></dt>
+ <dd>Une cha�ne de taille variable (longueur limit�e � 2^16). Elle
+ est cod�e comme suit : les deux premiers octets repr�sentent la
+ longueur de la cha�ne, les octets suivants constituent la cha�ne
+ proprement dite (y compris le '\0' final). Notez que la longueur
+ encod�e dans les deux premiers octets ne prend pas en compte le
+ '\0' final, de la m�me mani�re que <code>strlen</code>. Cela peut
+ pr�ter � confusion du point de vue de Java qui est surcharg� de
+ d�clarations d'autoincr�mentation �tranges destin�es � traiter
+ ces terminateurs. Je suppose que le but dans lequel cela a
+ �t� con�u ainsi �tait de permettre au code C d'�tre plus efficace
+ lors de la lecture de cha�nes en provenance du conteneur de
+ servlets -- avec le caract�re \0 final, le code C peut transmettre
+ des r�f�rences dans un seul tampon, sans avoir � effectuer de
+ copie. En l'absence du caract�re \0 final, le code C doit
+ effectuer une copie afin de pouvoir tenir compte de sa notion de
+ cha�ne.</dd>
+ </dl>
+
+ <section><title>Taille du paquet</title>
+ <p>Selon la majorit� du code, la taille maximale du paquet est de
+ <code>8 * 1024 bytes (8K)</code>. La taille r�elle du paquet est
+ encod�e dans l'en-t�te.</p>
+ </section>
+ <section><title>En-t�tes de paquet</title>
+ <p>Les paquets envoy�s par le serveur vers le conteneur commencent
+ par <code>0x1234</code>. Les paquets envoy�s par le conteneur vers
+ le serveur commencent par <code>AB</code> (c'est � dire le code
+ ASCII de A suivi du code ASCII de B). Ensuite, vient un entier (cod�
+ comme ci-dessus) repr�sentant la longueur des donn�es transmises.
+ Bien que ceci puisse faire croire que la taille maximale des donn�es
+ est de 2^16, le code d�finit en fait ce maximum � 8K.</p>
+ <table>
+ <columnspec><column width=".2"/><column width=".1"/><column width=".1"/><column width=".2"/><column width=".2"/><column width=".2"/></columnspec>
+ <tr>
+ <th colspan="6"><em>Format du paquet (Serveur->Conteneur)</em></th>
+ </tr>
+ <tr>
+ <th>Octet</th>
+ <td>0</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ <td>4...(n+3)</td>
+ </tr>
+ <tr>
+ <th>Contenu</th>
+ <td>0x12</td>
+ <td>0x34</td>
+ <td colspan="2">Taille des donn�es (n)</td>
+ <td>Data</td>
+ </tr>
+ </table>
+ <table>
+ <columnspec><column width=".2"/><column width=".1"/><column width=".1"/><column width=".2"/><column width=".2"/><column width=".2"/></columnspec>
+ <tr>
+ <th colspan="6"><em>Format du paquet
+ (Conteneur->Serveur)</em></th>
+ </tr>
+ <tr>
+ <th>Octet</th>
+ <td>0</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ <td>4...(n+3)</td>
+ </tr>
+ <tr>
+ <th>Contenu</th>
+ <td>A</td>
+ <td>B</td>
+ <td colspan="2">Taille des donn�es (n)</td>
+ <td>Data</td>
+ </tr>
+ </table>
+ <p>Pour la plupart des paquets, le premier octet de la charge utile
+ encode le type de message, � l'exception des paquets contenant un
+ corps de requ�te envoy�s du serveur vers le conteneur -- ils
+ comportent un en-t�te standard (<code>0x1234</code> suivi de la taille
+ du paquet), mais celui-ci n'est suivi d'aucun pr�fixe.</p>
+ <p>Le serveur web peut envoyer les messages suivants au conteneur
+ de servlets :</p>
+ <table>
+ <columnspec><column width=".2"/><column width=".3"/><column width=".5"/></columnspec>
+ <tr>
+ <td>Code</td>
+ <td>Type de paquet</td>
+ <td>Signification</td>
+ </tr>
+ <tr>
+ <td>2</td>
+ <td>Fait suivre la requ�te</td>
+ <td>D�bute le cycle de traitement de la requ�te avec les donn�es
+ qui suivent.</td>
+ </tr>
+ <tr>
+ <td>7</td>
+ <td>Arr�t</td>
+ <td>Le serveur web demande au conteneur de s'arr�ter.</td>
+ </tr>
+ <tr>
+ <td>8</td>
+ <td>Ping</td>
+ <td>Le serveur web demande au conteneur de prendre le contr�le
+ (phase de connexion s�curis�e).</td>
+ </tr>
+ <tr>
+ <td>10</td>
+ <td>CPing</td>
+ <td>Le serveur web demande au conteneur de r�pondre rapidement
+ avec un CPong.
+ </td>
+ </tr>
+ <tr>
+ <td>none</td>
+ <td>Donn�es</td>
+ <td>Taille (2 octets) et les donn�es correspondantes.</td>
+ </tr>
+ </table>
+ <p>� des fins de s�curit�, le conteneur n'effectuera r�ellement son
+ <code>Arr�t</code> que si la demande provient de la machine par
+ laquelle il est h�berg�.</p>
+ <p>Le premier paquet <code>Donn�es</code> est envoy� imm�diatement
+ apr�s le paquet <code>Faire suivre la requ�te</code> par le serveur
+ web.</p>
+ <p>Le conteneur de servlets peut envoyer les types de messages
+ suivants au serveur web :</p>
+ <table>
+ <columnspec><column width=".2"/><column width=".3"/><column width=".5"/></columnspec>
+ <tr>
+ <td>Code</td>
+ <td>Type de paquet</td>
+ <td>Signification</td>
+ </tr>
+ <tr>
+ <td>3</td>
+ <td>Envoi d'un tron�on de corps</td>
+ <td>Envoi d'un tron�on de corps depuis le conteneur de servlets
+ vers le serveur web (et probablement vers le navigateur).</td>
+ </tr>
+ <tr>
+ <td>4</td>
+ <td>Envoie les en-t�tes</td>
+ <td>Envoi des en-t�tes de r�ponse depuis le conteneur de
+ servlets vers le serveur web (et probablement vers le
+ navigateur).</td>
+ </tr>
+ <tr>
+ <td>5</td>
+ <td>Fin de la r�ponse</td>
+ <td>Marque la fin de la r�ponse (et par cons�quent du cycle de
+ traitement de la requ�te).
+ </td>
+ </tr>
+ <tr>
+ <td>6</td>
+ <td>R�ception du tron�on de corps suivant</td>
+ <td>R�ception de la suite des donn�es de la requ�te si elles
+ n'ont pas encore �t� enti�rement transmises.</td>
+ </tr>
+ <tr>
+ <td>9</td>
+ <td>R�ponse CPong</td>
+ <td>La r�ponse � une requ�te CPing</td>
+ </tr>
+ </table>
+ <p>Chacun des messages ci-dessus poss�de une structure interne
+ diff�rente dont vous trouverez les d�tails ci-dessous.</p>
+ </section>
+</section>
+<section id="rpacetstruct"><title>Structure des paquets de
+requ�te</title>
+ <p>Pour les messages de type <em>Faire suivre la requ�te</em> depuis
+ le serveur vers le conteneur :</p>
+ <example><pre>
+AJP13_FORWARD_REQUEST :=
+ prefix_code (byte) 0x02 = JK_AJP13_FORWARD_REQUEST
+ method (byte)
+ protocol (string)
+ req_uri (string)
+ remote_addr (string)
+ remote_host (string)
+ server_name (string)
+ server_port (integer)
+ is_ssl (boolean)
+ num_headers (integer)
+ request_headers *(req_header_name req_header_value)
+ attributes *(attribut_name attribute_value)
+ request_terminator (byte) OxFF
+ </pre></example>
+ <p>Les <code>request_headers</code> poss�dent la structure suivante
+ :
+ </p><example><pre>
+req_header_name :=
+ sc_req_header_name | (string) [voir ci-dessous pour la mani�re dont
+ ceci est interpr�t�]
+
+sc_req_header_name := 0xA0xx (integer)
+
+req_header_value := (string)
+</pre></example>
+ <p>Les <code>attributes</code> sont optionnels et poss�dent la
+ structure suivante :</p>
+ <example><pre>
+attribute_name := sc_a_name | (sc_a_req_attribute string)
+
+attribute_value := (string)
+
+ </pre></example>
+ <p>Un des en-t�tes les plus importants est
+ <code>content-length</code>, car il indique si le conteneur doit ou
+ non attendre un autre paquet imm�diatement.</p>
+ <section><title>Description d�taill�e de la requ�te que le serveur
+ fait suivre vers le conteneur
+ </title></section>
+ <section><title>Pr�fixe de la requ�te</title>
+ <p>Pour toutes les requ�tes, ce pr�fixe est 2. Voir ci-dessus pour
+ les d�tails des autres codes de pr�fixes.</p>
+ </section>
+ <section><title>M�thode</title>
+ <p>La m�thode HTTP, encod�e sous la forme d'un seul octet :</p>
+ <table>
+ <tr><td>Nom commande</td><td>Code</td></tr>
+ <tr><td>OPTIONS</td><td>1</td></tr>
+ <tr><td>GET</td><td>2</td></tr>
+ <tr><td>HEAD</td><td>3</td></tr>
+ <tr><td>POST</td><td>4</td></tr>
+ <tr><td>PUT</td><td>5</td></tr>
+ <tr><td>DELETE</td><td>6</td></tr>
+ <tr><td>TRACE</td><td>7</td></tr>
+ <tr><td>PROPFIND</td><td>8</td></tr>
+ <tr><td>PROPPATCH</td><td>9</td></tr>
+ <tr><td>MKCOL</td><td>10</td></tr>
+ <tr><td>COPY</td><td>11</td></tr>
+ <tr><td>MOVE</td><td>12</td></tr>
+ <tr><td>LOCK</td><td>13</td></tr>
+ <tr><td>UNLOCK</td><td>14</td></tr>
+ <tr><td>ACL</td><td>15</td></tr>
+ <tr><td>REPORT</td><td>16</td></tr>
+ <tr><td>VERSION-CONTROL</td><td>17</td></tr>
+ <tr><td>CHECKIN</td><td>18</td></tr>
+ <tr><td>CHECKOUT</td><td>19</td></tr>
+ <tr><td>UNCHECKOUT</td><td>20</td></tr>
+ <tr><td>SEARCH</td><td>21</td></tr>
+ <tr><td>MKWORKSPACE</td><td>22</td></tr>
+ <tr><td>UPDATE</td><td>23</td></tr>
+ <tr><td>LABEL</td><td>24</td></tr>
+ <tr><td>MERGE</td><td>25</td></tr>
+ <tr><td>BASELINE_CONTROL</td><td>26</td></tr>
+ <tr><td>MKACTIVITY</td><td>27</td></tr>
+ </table>
+ <p>Les versions futures d'ajp13 pourront transmettre des m�thodes
+ suppl�mentaires, m�me si elles ne font pas partie de cette
+ liste.</p>
+ </section>
+ <section><title>protocol, req_uri, remote_addr, remote_host, server_name,
+ server_port, is_ssl</title>
+ <p>Les significations de ces �l�ments sont triviales. Ils sont tous
+ obligatoires et seront envoy�s avec chaque requ�te.</p>
+ </section>
+ <section><title>En-t�tes</title>
+ <p>La structure de <code>request_headers</code> est la suivante
+ : tout d'abord, le nombre d'en-t�tes <code>num_headers</code> est
+ encod�, suivi d'une liste de paires nom d'en-t�te
+ <code>req_header_name</code> / valeur <code>req_header_value</code>.
+ Les noms d'en-t�tes courants sont cod�s sous forme d'entiers afin de
+ gagner de la place. Si le nom d'en-t�te ne fait partie de la liste
+ des en-t�tes courants, il est encod� normalement (une cha�ne de
+ caract�res pr�fix�e par la taille). La liste des en-t�tes courants
+ <code>sc_req_header_name</code> avec leurs codes se pr�sente comme
+ suit (il sont tous sensibles � la casse) :</p>
+ <table>
+ <tr><td>Nom</td><td>Valeur du code</td><td>Nom du code</td></tr>
+ <tr><td>accept</td><td>0xA001</td><td>SC_REQ_ACCEPT</td></tr>
+ <tr><td>accept-charset</td><td>0xA002</td><td>SC_REQ_ACCEPT_CHARSET
+ </td></tr>
+ <tr><td>accept-encoding</td><td>0xA003</td><td>SC_REQ_ACCEPT_ENCODING
+ </td></tr>
+ <tr><td>accept-language</td><td>0xA004</td><td>SC_REQ_ACCEPT_LANGUAGE
+ </td></tr>
+ <tr><td>authorization</td><td>0xA005</td><td>SC_REQ_AUTHORIZATION</td>
+ </tr>
+ <tr><td>connection</td><td>0xA006</td><td>SC_REQ_CONNECTION</td></tr>
+ <tr><td>content-type</td><td>0xA007</td><td>SC_REQ_CONTENT_TYPE</td>
+ </tr>
+ <tr><td>content-length</td><td>0xA008</td><td>SC_REQ_CONTENT_LENGTH</td>
+ </tr>
+ <tr><td>cookie</td><td>0xA009</td><td>SC_REQ_COOKIE</td></tr>
+ <tr><td>cookie2</td><td>0xA00A</td><td>SC_REQ_COOKIE2</td></tr>
+ <tr><td>host</td><td>0xA00B</td><td>SC_REQ_HOST</td></tr>
+ <tr><td>pragma</td><td>0xA00C</td><td>SC_REQ_PRAGMA</td></tr>
+ <tr><td>referer</td><td>0xA00D</td><td>SC_REQ_REFERER</td></tr>
+ <tr><td>user-agent</td><td>0xA00E</td><td>SC_REQ_USER_AGENT</td></tr>
+ </table>
+ <p>Le code Java qui lit ceci extrait l'entier repr�sent� par les
+ deux premiers octets, et si le premier octet est
+ <code>'0xA0'</code>, il utilise l'entier repr�sent� par le deuxi�me
+ octet comme index d'un tableau de noms d'en-t�tes. Si le premier
+ octet n'est pas <code>0xA0</code>, l'entier repr�sent� par les deux
+ octets est consid�r� comme la longueur d'une cha�ne qui est alors
+ lue.</p>
+ <p>Ceci ne peut fonctionner que si aucun nom d'en-t�te ne poss�de
+ une taille sup�rieure � <code>0x9FFF (==0xA000 - 1)</code>, ce qui
+ est vraisemblable, bien qu'un peu arbitraire.</p>
+ <note><title>Note:</title>
+ L'en-t�te <code>content-length</code> est extr�mement important.
+ S'il est pr�sent et non nul, le conteneur consid�re que la requ�te
+ poss�de un corps (une requ�te POST, par exemple), et lit
+ imm�diatement le paquet suivant dans le flux d'entr�e pour extraire
+ ce corps.
+ </note>
+ </section>
+ <section><title>Attributs</title>
+ <p>Les attributs pr�fix�s par <code>?</code> (par exemple
+ <code>?context</code>) sont tous optionnels. Chacun d'eux est
+ repr�sent� par un octet correspondant au type de l'attribut et par
+ sa valeur (cha�ne ou entier). Ils peuvent �tre envoy�s dans un ordre
+ quelconque (bien que le code C les envoie dans l'ordre ci-dessous).
+ Un code de terminaison sp�cial est envoy� pour signaler la fin de la
+ liste des attributs optionnels. La liste des codes est la suivante
+ :</p>
+ <table>
+ <tr><td>Information</td><td>Valeur code</td><td>Type de valeur</td><td>Note</td></tr>
+ <tr><td>?context</td><td>0x01</td><td>-</td><td>Non impl�ment�
+ actuellement
+ </td></tr>
+ <tr><td>?servlet_path</td><td>0x02</td><td>-</td><td>Non impl�ment�
+ actuellement
+ </td></tr>
+ <tr><td>?remote_user</td><td>0x03</td><td>String</td><td></td></tr>
+ <tr><td>?auth_type</td><td>0x04</td><td>String</td><td></td></tr>
+ <tr><td>?query_string</td><td>0x05</td><td>String</td><td></td></tr>
+ <tr><td>?jvm_route</td><td>0x06</td><td>String</td><td></td></tr>
+ <tr><td>?ssl_cert</td><td>0x07</td><td>String</td><td></td></tr>
+ <tr><td>?ssl_cipher</td><td>0x08</td><td>String</td><td></td></tr>
+ <tr><td>?ssl_session</td><td>0x09</td><td>String</td><td></td></tr>
+ <tr><td>?req_attribute</td><td>0x0A</td><td>String</td><td>Nom (le
+ nom de l'attribut vient ensuite)</td></tr>
+ <tr><td>?ssl_key_size</td><td>0x0B</td><td>Integer</td><td></td></tr>
+ <tr><td>are_done</td><td>0xFF</td><td>-</td><td>request_terminator</td></tr>
+ </table>
+ <p><code>context</code> et <code>servlet_path</code> ne sont pas
+ d�finis actuellement par le code C, et la majorit� du code Java
+ ignore compl�tement ce qui est envoy� par l'interm�diaire de ces
+ champs (il va m�me parfois s'interrompre si une cha�ne est
+ envoy�e apr�s un de ces codes). Je ne sais pas si c'est une bogue ou
+ une fonctionnalit� non impl�ment�e, ou tout simplement du code
+ obsol�te, mais en tout cas, il n'est pris en charge par aucune des
+ deux extr�mit�s de la connexion.</p>
+ <p><code>remote_user</code> et <code>auth_type</code> concernent
+ probablement l'authentification au niveau HTTP, et contiennent le
+ nom de l'utilisateur distant ainsi que le type d'authentification
+ utilis�e pour �tablir son identit� (� savoir Basic, Digest).</p>
+ <p><code>query_string</code>, <code>ssl_cert</code>,
+ <code>ssl_cipher</code> et <code>ssl_session</code> contiennent les
+ �l�ments HTTP et HTTPS correspondants.</p>
+ <p><code>jvm_route</code> est utilis� dans le cadre des sessions
+ persistantes, en associant une session utilisateur � une instance
+ Tomcat particuli�re en pr�sence de plusieurs r�partiteurs de
+ charge.</p>
+ <p>Au del� de cette liste de base, tout autre attribut
+ suppl�mentaire peut �tre envoy� via le code
+ <code>req_attribute</code> <code>0x0A</code>. Une paire de cha�nes
+ repr�sentant le nom et la valeur de l'attribut est envoy�e
+ imm�diatement apr�s chaque instance de ce code. Les variables
+ d'environnement sont transmises par cette m�thode.</p>
+ <p>Enfin, lorsque tous les attributs ont �t� transmis, le
+ terminateur d'attributs, <code>0xFF</code>, est envoy�. Ce dernier
+ indique � la fois la fin de la liste d'attributs et la fin du paquet
+ de la requ�te</p>
+ </section>
+</section>
+
+<section id="resppacketstruct"><title>Structure du paquet de la
+r�ponse</title>
+ <p>Pour les messages que le conteneur peut renvoyer au
+ serveur.</p>
+ <example><pre>
+AJP13_SEND_BODY_CHUNK :=
+ prefix_code 3
+ chunk_length (integer)
+ chunk *(byte)
+ chunk_terminator (byte) Ox00
+
+
+AJP13_SEND_HEADERS :=
+ prefix_code 4
+ http_status_code (integer)
+ http_status_msg (string)
+ num_headers (integer)
+ response_headers *(res_header_name header_value)
+
+res_header_name :=
+ sc_res_header_name | (string) [voir ci-dessous pour la mani�re
+ dont ceci est interpr�t�]
+
+sc_res_header_name := 0xA0 (byte)
+
+header_value := (string)
+
+AJP13_END_RESPONSE :=
+ prefix_code 5
+ reuse (boolean)
+
+
+AJP13_GET_BODY_CHUNK :=
+ prefix_code 6
+ requested_length (integer)
+ </pre></example>
+ <section><title>D�tails:</title></section>
+ <section><title>Envoi d'un tron�on de corps</title>
+ <p>Le tron�on se compose essentiellement de donn�es binaires et est
+ renvoy� directement au navigateur.</p>
+ </section>
+ <section><title>Envoi des en-t�tes</title>
+ <p>Les code et message d'�tat correspondent aux code et message HTTP
+ habituels (par exemple <code>200</code> et <code>OK</code>). Les
+ noms d'en-t�tes de r�ponses sont cod�s de la m�me fa�on que les noms
+ d'en-t�tes de requ�tes. Voir ci-dessus le codage des en-t�tes pour
+ plus de d�tails � propos de la mani�re dont les codes se distinguent
+ des cha�nes.<br />
+ Les codes des en-t�tes courants sont ::</p>
+ <table>
+ <tr><td>Nom</td><td>Valeur code</td></tr>
+ <tr><td>Content-Type</td><td>0xA001</td></tr>
+ <tr><td>Content-Language</td><td>0xA002</td></tr>
+ <tr><td>Content-Length</td><td>0xA003</td></tr>
+ <tr><td>Date</td><td>0xA004</td></tr>
+ <tr><td>Last-Modified</td><td>0xA005</td></tr>
+ <tr><td>Location</td><td>0xA006</td></tr>
+ <tr><td>Set-Cookie</td><td>0xA007</td></tr>
+ <tr><td>Set-Cookie2</td><td>0xA008</td></tr>
+ <tr><td>Servlet-Engine</td><td>0xA009</td></tr>
+ <tr><td>Status</td><td>0xA00A</td></tr>
+ <tr><td>WWW-Authenticate</td><td>0xA00B</td></tr>
+ </table>
+ <p>La valeur de l'en-t�te est cod�e imm�diatement apr�s le code ou
+ la cha�ne du nom d'en-t�te.</p>
+ </section>
+ <section><title>Fin de la r�ponse</title>
+ <p>Signale la fin de ce cycle de traitement de requ�te. Si le
+ drapeau <code>reuse</code> est � true <code>(toute valeur autre que
+ 0 en langage C pur)</code>, cette
+ connexion TCP peut �tre r�utilis�e pour traiter de nouvelles
+ requ�tes entrantes. Si <code>reuse</code> est � false
+ (==0), la connexion sera ferm�e.</p>
+ </section>
+ <section><title>R�ception d'un tron�on de corps</title>
+ <p>Le conteneur r�clame la suite des donn�es de la requ�te (dans le
+ cas o� la taille du corps �tait trop importante pour pouvoir �tre
+ contenue dans le premier paquet envoy�, o� lorsque la requ�te est
+ fractionn�e). Le serveur va alors envoyer un paquet contenant une
+ quantit� de donn�es correspondant au minimum de la
+ <code>request_length</code>, la taille maximale de corps envoy�e
+ <code>(8186 (8 Koctets - 6))</code>, et le nombre r�el d'octets
+ restants � envoyer pour ce corps de requ�te.<br/>
+ S'il ne reste plus de donn�es � transmettre pour ce corps de requ�te
+ (c'est � dire si le conteneur de servlets tente de lire au del� de
+ la fin du corps), le serveur va renvoyer un paquet <em>vide</em>
+ dont la charge utile est de longueur 0 et se pr�sentant sous la
+ forme <code>(0x12,0x34,0x00,0x00)</code>.</p>
+ </section>
+</section>
+
+
+</modulesynopsis>
Modified: httpd/httpd/trunk/docs/manual/mod/mod_proxy_ajp.xml.meta
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_proxy_ajp.xml.meta?rev=1780462&r1=1780461&r2=1780462&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_proxy_ajp.xml.meta (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_proxy_ajp.xml.meta Thu Jan 26 20:02:25 2017
@@ -8,6 +8,7 @@
<variants>
<variant>en</variant>
+ <variant>fr</variant>
<variant outdated="yes">ja</variant>
</variants>
</metafile>
Modified: httpd/httpd/trunk/docs/manual/mod/mod_proxy_balancer.html
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_proxy_balancer.html?rev=1780462&r1=1780461&r2=1780462&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_proxy_balancer.html (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_proxy_balancer.html Thu Jan 26 20:02:25 2017
@@ -4,6 +4,10 @@ URI: mod_proxy_balancer.html.en
Content-Language: en
Content-type: text/html; charset=ISO-8859-1
+URI: mod_proxy_balancer.html.fr
+Content-Language: fr
+Content-type: text/html; charset=ISO-8859-1
+
URI: mod_proxy_balancer.html.ja.utf8
Content-Language: ja
Content-type: text/html; charset=UTF-8