You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by lg...@apache.org on 2016/11/27 13:45:20 UTC
svn commit: r1771595 - in /httpd/httpd/branches/2.4.x/docs/manual/mod:
mod_mime_magic.xml.fr mod_nw_ssl.xml.fr mod_proxy_ajp.xml.fr
Author: lgentis
Date: Sun Nov 27 13:45:20 2016
New Revision: 1771595
URL: http://svn.apache.org/viewvc?rev=1771595&view=rev
Log:
UTF-8 encoding.
Modified:
httpd/httpd/branches/2.4.x/docs/manual/mod/mod_mime_magic.xml.fr
httpd/httpd/branches/2.4.x/docs/manual/mod/mod_nw_ssl.xml.fr
httpd/httpd/branches/2.4.x/docs/manual/mod/mod_proxy_ajp.xml.fr
Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/mod_mime_magic.xml.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/mod_mime_magic.xml.fr?rev=1771595&r1=1771594&r2=1771595&view=diff
==============================================================================
--- httpd/httpd/branches/2.4.x/docs/manual/mod/mod_mime_magic.xml.fr (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/mod/mod_mime_magic.xml.fr Sun Nov 27 13:45:20 2016
@@ -1,4 +1,4 @@
-<?xml version="1.0"?>
+<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
<!-- English Revision : 1334018 -->
@@ -25,55 +25,55 @@
<modulesynopsis metafile="mod_mime_magic.xml.meta">
<name>mod_mime_magic</name>
-<description>Détermine le type MIME d'un fichier à partir de quelques
+<description>Détermine le type MIME d'un fichier à partir de quelques
octets de son contenu</description>
<status>Extension</status>
<sourcefile>mod_mime_magic.c</sourcefile>
<identifier>mime_magic_module</identifier>
<summary>
- <p>Ce module permet de déterminer le <glossary ref="mime-type">type
- MIME</glossary> des fichiers de la même manière que la commande Unix
- <code>file(1)</code>, à savoir en se basant sur les premiers octets
- du fichier. Il est conçu comme une "seconde ligne de défense" pour
- les cas où <module>mod_mime</module> ne parvient pas à déterminer le
+ <p>Ce module permet de déterminer le <glossary ref="mime-type">type
+ MIME</glossary> des fichiers de la même manière que la commande Unix
+ <code>file(1)</code>, à savoir en se basant sur les premiers octets
+ du fichier. Il est conçu comme une "seconde ligne de défense" pour
+ les cas où <module>mod_mime</module> ne parvient pas à déterminer le
type du fichier.</p>
- <p>Ce module est dérivé d'une version libre de la commande Unix
+ <p>Ce module est dérivé d'une version libre de la commande Unix
<code>file(1)</code> qui utilise des "nombres magiques" et autres
marques distinctives issus du contenu du fichier pour essayer de
- déterminer le type de contenu. Ce module n'est activé que si le
- fichier magique est spécifié par la directive <directive
+ déterminer le type de contenu. Ce module n'est activé que si le
+ fichier magique est spécifié par la directive <directive
module="mod_mime_magic">MimeMagicFile</directive>.</p>
</summary>
<section id="format"><title>Format du fichier magique</title>
- <p>Le fichier contient du texte ASCII sur 4 à 5 colonnes. Les lignes
- vides sont autorisées mais ignorées. Toute ligne commençant par un
- dièse (<code>#</code>) est un commentaire. Les autres lignes sont
- interprétées en colonnes comme suit :</p>
+ <p>Le fichier contient du texte ASCII sur 4 à 5 colonnes. Les lignes
+ vides sont autorisées mais ignorées. Toute ligne commençant par un
+ dièse (<code>#</code>) est un commentaire. Les autres lignes sont
+ interprétées en colonnes comme suit :</p>
<table style="zebra" border="1">
<columnspec><column width=".15"/><column width=".8"/></columnspec>
<tr><th>Colonne</th><th>Description</th></tr>
<tr><td>1</td>
- <td>numéro de l'octet à partir duquel la vérification débute<br />
- "<code>></code>" indique une dépendance par rapport à la
- dernière ligne non-"<code>></code>"</td></tr>
+ <td>numéro de l'octet à partir duquel la vérification débute<br />
+ "<code>></code>" indique une dépendance par rapport à la
+ dernière ligne non-"<code>></code>"</td></tr>
<tr><td>2</td>
- <td><p>type de donnée à rechercher</p>
+ <td><p>type de donnée à rechercher</p>
<table border="1">
<columnspec><column width=".2"/><column width=".7"/></columnspec>
<tr><td><code>byte</code></td>
- <td>caractère unique</td></tr>
+ <td>caractère unique</td></tr>
<tr><td><code>short</code></td>
<td>entier sur 16 bits selon l'ordre de la machine</td></tr>
<tr><td><code>long</code></td>
<td>entier sur 32 bits selon l'ordre de la machine</td></tr>
<tr><td><code>string</code></td>
- <td>chaîne de taille choisie</td></tr>
+ <td>chaîne de taille choisie</td></tr>
<tr><td><code>date</code></td>
<td>date au format entier long (secondes depuis le temps Unix epoch/1970)</td></tr>
<tr><td><code>beshort</code></td>
@@ -91,7 +91,7 @@ octets de son contenu</description>
</table></td></tr>
<tr><td>3</td>
- <td>contenu des données à rechercher</td></tr>
+ <td>contenu des données à rechercher</td></tr>
<tr><td>4</td>
<td>type MIME si correspondance</td></tr>
@@ -101,7 +101,7 @@ octets de son contenu</description>
</table>
<p>Par exemple, les lignes du fichier magique suivantes
- permettraient de reconnaître certains formats audio :</p>
+ permettraient de reconnaître certains formats audio :</p>
<example>
<pre># Sun/NeXT audio data
@@ -116,10 +116,10 @@ octets de son contenu</description>
>12 belong 23 audio/x-adpcm</pre>
</example>
- <p>Et celles-ci permettraient de reconnaître la différence entre les
+ <p>Et celles-ci permettraient de reconnaître la différence entre les
fichiers <code>*.doc</code> qui contiennent des documents Microsoft
Word et les documents FrameMaker (ce sont des formats de fichiers
- incompatibles qui possèdent le même suffixe).</p>
+ incompatibles qui possèdent le même suffixe).</p>
<example>
<pre># Frame
@@ -137,45 +137,45 @@ octets de son contenu</description>
0 string \333\245-\0\0\0 application/msword</pre>
</example>
- <p>Un champ optionnel codage MIME peut être ajouté dans la cinquième
- colonne. Par exemple, cette ligne permet de reconnaître les fichiers
- compressés par gzip et définissent le type de codage.</p>
+ <p>Un champ optionnel codage MIME peut être ajouté dans la cinquième
+ colonne. Par exemple, cette ligne permet de reconnaître les fichiers
+ compressés par gzip et définissent le type de codage.</p>
<example>
-<pre># gzip (GNU zip, à ne pas confondre avec
+<pre># gzip (GNU zip, à ne pas confondre avec
# l'archiveur zip [Info-ZIP/PKWARE])
0 string \037\213 application/octet-stream x-gzip</pre>
</example>
</section>
-<section id="performance"><title>Problèmes liés aux performances</title>
- <p>Ce module n'est pas fait pour tous les systèmes. Si votre système
- parvient à peine à supporter sa charge, ou si vous testez les
- performances d'un serveur web, il est déconseillé d'utiliser ce
- module car son fonctionnement a un prix en matière de ressources
- consommées.</p>
+<section id="performance"><title>Problèmes liés aux performances</title>
+ <p>Ce module n'est pas fait pour tous les systèmes. Si votre système
+ parvient à peine à supporter sa charge, ou si vous testez les
+ performances d'un serveur web, il est déconseillé d'utiliser ce
+ module car son fonctionnement a un prix en matière de ressources
+ consommées.</p>
- <p>Des efforts ont cependant été fournis pour améliorer les
+ <p>Des efforts ont cependant été fournis pour améliorer les
performances du code original de la commande <code>file(1)</code> en
- l'adaptant pour fonctionner sur un serveur web à forte charge. Il a
- été conçu pour un serveur sur lequel des milliers d'utilisateurs
- publient leurs propres documents, ce qui est probablement très
- courant sur un intranet. Il s'avère souvent bénéfique qu'un serveur
- puisse prendre des décisions plus pertinentes à propos du contenu
+ l'adaptant pour fonctionner sur un serveur web à forte charge. Il a
+ été conçu pour un serveur sur lequel des milliers d'utilisateurs
+ publient leurs propres documents, ce qui est probablement très
+ courant sur un intranet. Il s'avère souvent bénéfique qu'un serveur
+ puisse prendre des décisions plus pertinentes à propos du contenu
d'un fichier que celles se basant sur le nom du fichier seul, ne
serait-ce que pour diminuer le nombre d'appels du type "pourquoi ma
page ne s'affiche-t-elle pas ?" survenant lorsque les utilisateurs
- nomment leurs fichiers incorrectement. Vous devez déterminer si la
- charge supplémentaire convient à votre environnement.</p>
+ nomment leurs fichiers incorrectement. Vous devez déterminer si la
+ charge supplémentaire convient à votre environnement.</p>
</section>
<section id="notes"><title>Notes</title>
<p>Les notes suivantes s'appliquent au module
<module>mod_mime_magic</module> et sont incluses ici pour
- conformité avec les restrictions de copyright des contributeurs
- qui requièrent de les accepter.</p>
- <p>Note de traduction : ces informations de type légal ne sont pas traductibles</p>
+ conformité avec les restrictions de copyright des contributeurs
+ qui requièrent de les accepter.</p>
+ <p>Note de traduction : ces informations de type légal ne sont pas traductibles</p>
<note>
<p>mod_mime_magic: MIME type lookup via file magic numbers<br />
@@ -257,22 +257,22 @@ octets de son contenu</description>
<directivesynopsis>
<name>MimeMagicFile</name>
-<description>Active la détermination du type MIME en se basant sur le
+<description>Active la détermination du type MIME en se basant sur le
contenu du fichier et en utilisant le fichier magique
-spécifié</description>
+spécifié</description>
<syntax>MimeMagicFile <var>chemin-fichier</var></syntax>
<contextlist><context>server config</context><context>virtual host</context>
</contextlist>
<usage>
<p>La directive <directive>MimeMagicFile</directive> permet
- d'activer ce module, le fichier par défaut fourni étant
- <code>conf/magic</code>. Les chemins sans slash '/' de début sont
- relatifs au répertoire défini par la directive <directive
+ d'activer ce module, le fichier par défaut fourni étant
+ <code>conf/magic</code>. Les chemins sans slash '/' de début sont
+ relatifs au répertoire défini par la directive <directive
module="core">ServerRoot</directive>. Les serveurs virtuels
- utilisent le même fichier que le serveur principal sauf si un
- fichier spécifique a été défini pour ce serveur virtuel, auquel cas
- c'est ce dernier fichier qui sera utilisé.</p>
+ utilisent le même fichier que le serveur principal sauf si un
+ fichier spécifique a été défini pour ce serveur virtuel, auquel cas
+ c'est ce dernier fichier qui sera utilisé.</p>
<example><title>Exemple</title>
<highlight language="config">
Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/mod_nw_ssl.xml.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/mod_nw_ssl.xml.fr?rev=1771595&r1=1771594&r2=1771595&view=diff
==============================================================================
--- httpd/httpd/branches/2.4.x/docs/manual/mod/mod_nw_ssl.xml.fr (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/mod/mod_nw_ssl.xml.fr Sun Nov 27 13:45:20 2016
@@ -1,4 +1,4 @@
-<?xml version="1.0"?>
+<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
<!-- English Revision : 1174747 -->
@@ -32,39 +32,39 @@
<compatibility>NetWare seulement</compatibility>
<summary>
- <p>Ce module active le chiffrement SSL sur un port spécifique. Il
- s'appuie sur la fonctionnalité de chiffrement SSL intégrée au
- système d'exploitation Netware.</p>
+ <p>Ce module active le chiffrement SSL sur un port spécifique. Il
+ s'appuie sur la fonctionnalité de chiffrement SSL intégrée au
+ système d'exploitation Netware.</p>
</summary>
<directivesynopsis>
<name>SecureListen</name>
<description>Active le chiffrement SSL pour le port
-spécifié</description>
+spécifié</description>
<syntax>SecureListen [<var>adresse-IP</var>:]<var>num-port</var>
<var>nom-certificat</var> [MUTUAL]</syntax>
<contextlist><context>server config</context></contextlist>
<usage>
- <p>Cette directive permet de spécifier le port et le nom de
- certificat de style eDirectory qui seront utilisés pour activer le
- chiffrement SSL. En outre, un troisième paramètre optionnel permet
+ <p>Cette directive permet de spécifier le port et le nom de
+ certificat de style eDirectory qui seront utilisés pour activer le
+ chiffrement SSL. En outre, un troisième paramètre optionnel permet
d'activer l'authentification mutuelle.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>NWSSLTrustedCerts</name>
-<description>Liste de certificats clients supplémentaires</description>
+<description>Liste de certificats clients supplémentaires</description>
<syntax>NWSSLTrustedCerts <var>nom-fichier</var>
[<var>nom-fichier</var>] ...</syntax>
<contextlist><context>server config</context></contextlist>
<usage>
- <p>Cette directive permet de spécifier une liste de fichiers (au
- format DER) contenant des certificats clients utilisés lors de
- l'établissement d'une connexion SSL mandatée. Chaque certificat
- client utilisé par un serveur doit être enregistré séparément dans
+ <p>Cette directive permet de spécifier une liste de fichiers (au
+ format DER) contenant des certificats clients utilisés lors de
+ l'établissement d'une connexion SSL mandatée. Chaque certificat
+ client utilisé par un serveur doit être enregistré séparément dans
son propre fichier <code>.der</code>.</p>
</usage>
</directivesynopsis>
@@ -72,15 +72,15 @@ spécifié</description>
<directivesynopsis>
<name>NWSSLUpgradeable</name>
<description>Permet de promouvoir une connexion non SSL au statut de
-connexion SSL à la demande</description>
+connexion SSL à la demande</description>
<syntax>NWSSLUpgradeable [<var>adresse-IP</var>:]<var>num-port</var></syntax>
<contextlist><context>server config</context></contextlist>
<usage>
- <p>Cette directive permet de promouvoir une connexion établie sur
- l'adresse IP et/ou le port spécifiés au statut de connexion SSL à la
- demande du client. L'adresse et/ou le port doivent avoir été définis
- au préalable par une directive <directive
+ <p>Cette directive permet de promouvoir une connexion établie sur
+ l'adresse IP et/ou le port spécifiés au statut de connexion SSL à la
+ demande du client. L'adresse et/ou le port doivent avoir été définis
+ au préalable par une directive <directive
module="mpm_common">Listen</directive>.</p>
</usage>
</directivesynopsis>
Modified: httpd/httpd/branches/2.4.x/docs/manual/mod/mod_proxy_ajp.xml.fr
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/docs/manual/mod/mod_proxy_ajp.xml.fr?rev=1771595&r1=1771594&r2=1771595&view=diff
==============================================================================
--- httpd/httpd/branches/2.4.x/docs/manual/mod/mod_proxy_ajp.xml.fr (original)
+++ httpd/httpd/branches/2.4.x/docs/manual/mod/mod_proxy_ajp.xml.fr Sun Nov 27 13:45:20 2016
@@ -1,4 +1,4 @@
-<?xml version="1.0"?>
+<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
<!-- English Revision: 1673563 -->
@@ -33,20 +33,20 @@
<compatibility>Disponible depuis la version 2.1 d'Apache</compatibility>
<summary>
- <p>Ce module nécessite le chargement de <module
+ <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
+ 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
+ <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
+ <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>
+ votre réseau, mais aussi pour l'Internet au sens large. </p>
</note>
</summary>
@@ -56,8 +56,8 @@ 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,
+ 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>
@@ -66,8 +66,8 @@ d'environnement</a></seealso>
</highlight>
</example>
- <p>On peut aussi configurer un répartiteur de charge :</p>
- <example><title>Mandataire inverse avec répartiteur de charge</title>
+ <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
@@ -78,143 +78,143 @@ ProxyPass "/app" "balancer://cluster/app
</highlight>
</example>
- <p>Notez qu'en général, la directive <directive
+ <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>
+ 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
+ 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)
+ 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>
+ <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
+ <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
+ <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>
+ 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
+ <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,
+ 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>
+ 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
+ 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
+ <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>
+ 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
+ <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
+ <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>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>
+ 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>
+ <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
+ <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>
+ <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>
+ <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
+ <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
+ 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
+ é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>
+ 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>
+ <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>
@@ -232,7 +232,7 @@ ProxyPassReverse "/apps/foo" "http://www
<th>Contenu</th>
<td>0x12</td>
<td>0x34</td>
- <td colspan="2">Taille des données (n)</td>
+ <td colspan="2">Taille des données (n)</td>
<td>Data</td>
</tr>
</table>
@@ -254,15 +254,15 @@ ProxyPassReverse "/apps/foo" "http://www
<th>Contenu</th>
<td>A</td>
<td>B</td>
- <td colspan="2">Taille des données (n)</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>
+ 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>
@@ -274,39 +274,39 @@ ProxyPassReverse "/apps/foo" "http://www
</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
+ <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>
+ <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>
+ <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
+ <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>
+ <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
+ <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>
@@ -319,43 +319,43 @@ ProxyPassReverse "/apps/foo" "http://www
</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
+ <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
+ <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>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>
+ <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>
+ <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>
+ <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
+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 :=
@@ -373,18 +373,18 @@ AJP13_FORWARD_REQUEST :=
attributes *(attribut_name attribute_value)
request_terminator (byte) OxFF
</pre></example>
- <p>Les <code>request_headers</code> possèdent la structure suivante
+ <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 | (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
+ <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)
@@ -392,18 +392,18 @@ attribute_name := sc_a_name | (sc_a_req_
attribute_value := (string)
</pre></example>
- <p>Un des en-têtes les plus importants est
+ <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
+ 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><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>
+ <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>
@@ -434,26 +434,26 @@ attribute_value := (string)
<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
+ <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>
+ <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>
+ <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
+ : 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>
+ 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>
@@ -477,39 +477,39 @@ attribute_value := (string)
<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
+ <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
+ <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
+ <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
+ 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
+ <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
+ 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
+ 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é
+ <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é
+ <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>
@@ -525,39 +525,39 @@ attribute_value := (string)
<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>
+ 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>
+ 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
+ é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>
+ <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>
+réponse</title>
<p>Pour les messages que le conteneur peut renvoyer au
serveur.</p>
<example><pre>
@@ -576,8 +576,8 @@ AJP13_SEND_HEADERS :=
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 | (string) [voir ci-dessous pour la manière
+ dont ceci est interprété]
sc_res_header_name := 0xA0 (byte)
@@ -592,19 +592,19 @@ 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><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
+ <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>
+ 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>
@@ -619,30 +619,30 @@ AJP13_GET_BODY_CHUNK :=
<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>
+ <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
+ <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
+ 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
+ dont la charge utile est de longueur 0 et se présentant sous la
forme <code>(0x12,0x34,0x00,0x00)</code>.</p>
</section>
</section>