<?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: 1824076:1825742 (outdated) -->
+<!-- English Revision: 1825742 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<p>L'ordre dans lequel s'effectue la recherche quand on utilise le
port physique est le suivant :</p>
<dl>
- <dt><code>UseCanonicalName On</code></dt>
+ <dt><code>UseCanonicalName Off | DNS</code></dt>
<dd>
<ol>
+ <li>Port extrait de l'en-tête <code>Host:</code></li>
+ <li>Port physique (seulement avec
+ <directive>UseCanonicalPhysicalPort</directive> ON)</li>
<li>Port indiqué dans <directive module="core">Servername</directive></li>
- <li>Port physique</li>
<li>Port par défaut</li>
</ol>
</dd>
- <dt><code>UseCanonicalName Off | DNS</code></dt>
+ <dt><code>UseCanonicalName On</code></dt>
<dd>
<ol>
- <li>Port spécifié dans l'en-tête <code>Host:</code></li>
- <li>Port physique</li>
<li>Port spécifié par <directive module="core">Servername</directive></li>
+ <li>Port physique (seulement avec
+ <directive>UseCanonicalPhysicalPort</directive> ON)</li>
<li>Port par défaut</li>
</ol>
</dd>
- </dl>
+ </dl>
- <p>Avec <code>UseCanonicalPhysicalPort Off</code>, on reprend
- l'ordre ci-dessus en supprimant "Port physique".</p>
+ <p>Les ports physiques ne sont inclus dans la recherche qu'avec
+ <directive>UseCanonicalPhysicalPort</directive> ON</p>
</note>
</usage>
<?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: 1813997:1825757 (outdated) -->
+<!-- English Revision: 1825757 -->
<!-- French translation : Lucien GENTIS -->
<!--
href="http://www.example.com/appserver/foo/bar.html">foobar</a></code>,
ce qui permet de rendre le serveur d'applications accessible depuis
l'extérieur.</p>
-
-<p>mod_proxy_html a été développé à l'origine à WebÞing, dont la <a
-href="http://apache.webthing.com/mod_proxy_html/">documentation</a>
-détaillée pourra s'avérer utile aux utilisateurs.</p>
</summary>
+<section id="intro"><title>Introduction</title>
+<p>mod_proxy_html est apparu en tant que module tiers avec les versions 2.0.x du
+serveur HTTP Apache. Il a ensuite été donné à l'ASF en 2011 avec le module
+<module>mod_xml2enc</module> (voir <a href="#i18n">Internationalisation</a>), et
+fait maintenant partie des modules standards de HTTPD 2.4 et de ses versions de
+développement.</p>
+</section>
+<section id="custom"><title>Interprétation HTML personnalisée</title>
+<p>mod_proxy_html utilise en interne le module HTMLParser fourni par la
+bibliothèque tierce <a href="http://xmlsoft.org/">libxml2</a>. A la différence
+des autres interpréteurs libxml2, HTMLParser traite les documents HTML sans
+imposer à ces derniers d'être bien formés du point de vue XML. En particulier,
+il sait gérer les tags implicites - comme le </p> fermant - et les insère
+dans le flux des évènements SAX utilisé par mod_proxy_html. Il possède aussi une
+connaissance explicite des standards HTML 4 et XHTML 1 du W3C, et peut en
+corriger certaines erreurs.</p>
+<p>mod_proxy_html offre toute une panoplie d'options permettant de contrôler
+l'interprétation du code HTML. La correction d'erreur peut être activée (selon
+votre choix de standard HTML) ou désactivée via la directive
+<directive>ProxyHTMLDocType</directive>. Et à la demande générale, il peut être
+configuré pour traiter les éléments et attributs non standards en tant que liens
+qui devront peut-être être réécrits, et pour réécrire les liens dans les contenus
+embarqués non-HTML (feuilles de style et scripts). Notez que ce module ne
+convient pas pour traiter les feuilles de style ou scripts externes ; pour ces
+derniers, vous devez utiliser un autre interpréteur comme
+<module>mod_substitute</module> ou <module>mod_sed</module>. Les principales
+directives permettant de personnaliser l'interprétation du code HTML sont
+<directive>ProxyHTMLLinks</directive> et <directive>ProxyHTMLEvents</directive>.
+Par défaut, elles sont définies dans le fichier de configuration
+<var>proxy-html.conf</var> qui contient aussi des commentaires pour vous aider à
+personnaliser votre interpréteur si nécessaire. </p>
+<note>Pour des raisons historiques, configurer mod_proxy_html pour réécrire les
+URLs dans les évènements de scripting n'entraîne pas par défaut la réécriture des
+URLs dans les feuilles de style. Ce comportement peut être modifié en
+décommentant la ligne correspondante du fichier <var>proxy-html.conf</var> comme
+indiqué dans la documentation que contient ce dernier.</note>
+
+</section>
+<section id="i18n"><title>Internationalisation</title>
+<p>mod_proxy_html utilise en interne un interpréteur HTML intelligent fourni par
+la bibliothèque tierce <a href="http://xmlsoft.org/">libxml2</a>. L'interpréteur
+utilise Unicode (UTF-8) en interne. Ceci complexifie la gestion
+des autres encodages nécessaires pour traiter de nombreux sites web dont le
+langage est autre que l'anglais. Si ce traitement n'est pas effectué
+de manière appropriée, les sites web qui utilisent des caractères non-ASCII dans un
+codage autre que UTF-8 (Unicode) ne s'afficheront pas correctement.</p>
+<p>Entre sa première version en 2003 et sa donnation à Apache en 2011, le
+support de l'internationalisation (i18n) est parti de rien pour arriver à une
+structure sophistiquée capable d'appliquer des règles issues de HTTP, HTML et
+XML pour détecter le codage d'un document et ainsi le traiter correctement. Ce
+traitement était cependant commun à mod_proxy_html et à d'autres modules
+utilisant libxml2, et plutôt que de le maintenir au niveau de chacun de ces
+modules, il parut sensé de l'extraire de ces derniers pour en faire
+un module à part entière. Ce module est <module>mod_xml2enc</module> et il doit
+être chargé pour que l'internationalisation fonctionne.</p>
+<p>L'interaction entre mod_proxy_html et mod_xml2enc est trop complexe pour être
+configurée en utilisant les règles de filtrage classiques, y compris les
+directives de <module>mod_filter</module>. Ainsi, même si mod_proxy_html peut
+quand-même être configuré via les directives de filtrage classiques, ce ne sera
+pas suffisant pour le support de l'internationalisation. A cet effet, on a
+introduit la nouvelle directive <directive>ProxyHTMLEnable</directive> qui
+permet de configurer à la fois le filtre de mod_proxy_html et mod_xml2enc. Il
+est d'ailleurs recommandé de toujours utiliser ProxyHTMLEnable, même
+si le support de l'internationalisation n'est pas nécessaire. <strong>Notez que
+ceci constitue un changement par rapport aux précédentes versions où
+mod_proxy_html était activé via les directives de filtrage.</strong></p>
+
+</section>
+
+
<directivesynopsis>
<name>ProxyHTMLMeta</name>
<description>Active ou désactive une préinterprétation supplémentaire
d'évènements pour chaque niveau.</p>
<p>Le fichier <var>proxy-html.conf</var> fournit une configuration par
défaut et définit les évènements selon les standards
-HTML 4 et XHTML 1.</p>
+HTML 4 et XHTML 1. Cette configuration peut être adaptée pour s'appliquer aux
+URLs embarquées dans les attributs des feuilles de style CSS en ajoutant
+l'attribut <var>style</var> à ProxyHTMLEvents, même s'il n'existe pas dans la
+configuration par défaut.</p>
</usage>
</directivesynopsis>
projects / apache / commitdiff