httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From n.@apache.org
Subject svn commit: r155795 - in httpd/httpd/branches/2.0.x/docs/manual: dns-caveats.xml.fr dso.xml.fr env.xml.fr filter.xml.fr handler.xml.fr
Date Tue, 01 Mar 2005 15:52:15 GMT
Author: nd
Date: Tue Mar  1 07:52:13 2005
New Revision: 155795

URL: http://svn.apache.org/viewcvs?view=rev&rev=155795
Log:
Update French translation

* manual/dns-caveats.xml.fr
* manual/handler.xml.fr
* manual/dso.xml.fr
* manual/filter.xml.fr
* manual/env.xml.fr
    new translations

Translated by: Vincent Deffontaines <vincent gryzor.com>
Reviewed by: alain B <chbok hotmail.com>

Added:
    httpd/httpd/branches/2.0.x/docs/manual/dns-caveats.xml.fr   (with props)
    httpd/httpd/branches/2.0.x/docs/manual/dso.xml.fr   (with props)
    httpd/httpd/branches/2.0.x/docs/manual/env.xml.fr   (with props)
    httpd/httpd/branches/2.0.x/docs/manual/filter.xml.fr   (with props)
    httpd/httpd/branches/2.0.x/docs/manual/handler.xml.fr   (with props)

Added: httpd/httpd/branches/2.0.x/docs/manual/dns-caveats.xml.fr
URL: http://svn.apache.org/viewcvs/httpd/httpd/branches/2.0.x/docs/manual/dns-caveats.xml.fr?view=auto&rev=155795
==============================================================================
--- httpd/httpd/branches/2.0.x/docs/manual/dns-caveats.xml.fr (added)
+++ httpd/httpd/branches/2.0.x/docs/manual/dns-caveats.xml.fr Tue Mar  1 07:52:13 2005
@@ -0,0 +1,239 @@
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
+<!-- English Revision: 151405 -->
+<!-- French Translation by Vincent Deffontaines, review by alain B -->
+
+<!--
+ Copyright 2005 The Apache Software Foundation or its licensors, as
+ applicable.
+
+ Licensed 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.
+-->
+
+<manualpage metafile="dns-caveats.xml.meta">
+
+  <title>Problèmes DNS avec Apache</title>
+
+  <summary>
+    <p>L'ensemble de cette page pourrait se résumer à la phrase&nbsp;: ne 
+    jamais configurer Apache de telle sorte qu'il s'appuie sur des 
+    résolutions DNS pour parcourir ses fichiers de configuration. 
+    Une telle configuration risque d'engendrer des problèmes de 
+    fiabilité (le serveur peut ne pas démarrer), des attaques de type 
+    déni et de vol de service (comme par exemple des utilisateurs volant 
+    les hits d'autres utilisateurs).</p>
+  </summary>
+
+  <section id="example">
+    <title>Un exemple simple</title>
+
+    <example>
+      &lt;VirtualHost www.abc.dom&gt; <br />
+      ServerAdmin webgirl@abc.dom <br />
+      DocumentRoot /www/abc <br />
+      &lt;/VirtualHost&gt;
+    </example>
+
+    <p>Pour qu'Apache fonctionne correctement, il a absolument besoin 
+    de deux informations pour chacun de ses serveurs virtuels&nbsp;:
+    <directive module="core">ServerName</directive> ainsi qu'au moins une
+    adresse IP à laquelle le serveur s'attachera pour répondre.
+    L'exemple ci-dessus ne précise pas l'adresse IP, si bien qu'Apache doit
+    utiliser le DNS pour trouver l'adresse de <code>www.abc.dom</code>. 
+    Si, pour une raison ou une autre, le DNS ne fonctionne pas au moment 
+    où Apache lit ses fichiers de configuration, le serveur virtuel 
+    <strong>ne sera pas configuré</strong>. Il sera incapable de répondre 
+    aux requêtes. Jusqu'à la version 1.2, Apache refusait même de 
+    démarrer dans ce cas de figure.</p>
+
+    <p>Prenons le cas où l'adresse de <code>www.abc.dom</code> est 10.0.0.1 
+    et considérons cet extrait de configuration&nbsp;:</p>
+
+    <example>
+      &lt;VirtualHost 10.0.0.1&gt; <br />
+      ServerAdmin webgirl@abc.dom <br />
+      DocumentRoot /www/abc <br />
+      &lt;/VirtualHost&gt;
+    </example>
+
+    <p>Cette fois, Apache a besoin d'utiliser la résolution DNS 
+    inversée pour déterminer le nom <code>ServerName</code> de ce 
+    serveur virtuel. Si cette résolution n'aboutit pas, le serveur 
+    virtuel sera partiellement mis hors service (jusqu'à la version 
+    1.2, Apache refusait même de démarrer dans ce cas de figure). Si 
+    le serveur virtuel est un serveur basé sur un nom (name-based), 
+    il sera totalement hors service, mais s'il s'agit d'un serveur 
+    par IP (IP-based), il fonctionnera correctement. Cependant, dans 
+    le cas où Apache doit générer une adresse complète URL en 
+    s'appuyant sur le nom du serveur, il échouera à fournir une 
+    adresse valide.</p>
+
+    <p>Voici un extrait de configuration qui résout ces deux problèmes&nbsp;:</p>
+
+    <example>
+      &lt;VirtualHost 10.0.0.1&gt; <br />
+      ServerName www.abc.dom <br />
+      ServerAdmin webgirl@abc.dom <br />
+      DocumentRoot /www/abc <br />
+      &lt;/VirtualHost&gt;
+    </example>
+  </section>
+
+  <section id="denial">
+    <title>Déni de Service</title>
+
+    <p>Il existe (au moins) deux problèmes possibles de déni de service.
+    Les versions d'Apache antérieures à 1.2 ne démarreront pas si 
+    l'une des deux requêtes DNS citées ci-dessus n'aboutissent pas pour 
+    un de vos serveurs virtuels. Dans certains cas, les entrées DNS 
+    sont hors de contrôle de l'administrateur Web&nbsp;; par exemple si 
+    <code>abc.dom</code> appartient à un de vos clients qui a la 
+    maîtrise de son propre DNS, celui-ci peut empêcher votre serveur 
+    Web (avant la version 1.2) de démarrer, simplement en effaçant 
+    l'enregistrement <code>www.abc.dom</code> du DNS.</p>
+    
+    <p>L'autre problème possible est bien plus pernicieux. Dans la 
+    configuration suivante&nbsp;:</p>
+
+    <example>
+      &lt;VirtualHost www.abc.dom&gt; <br />
+      &nbsp;&nbsp;ServerAdmin webgirl@abc.dom <br />
+      &nbsp;&nbsp;DocumentRoot /www/abc <br />
+      &lt;/VirtualHost&gt; <br />
+      <br />
+      &lt;VirtualHost www.def.dom&gt; <br />
+      &nbsp;&nbsp;ServerAdmin webguy@def.dom <br />
+      &nbsp;&nbsp;DocumentRoot /www/def <br />
+      &lt;/VirtualHost&gt;
+    </example>
+
+    <p>Supposons que <code>www.abc.dom</code> ait l'adresse 10.0.0.1, 
+    et que <code>www.def.dom</code> ait l'adresse 10.0.0.2. Supposons 
+    également que <code>def.com</code> ait la main sur son DNS. 
+    Cette configuration peut permettre à <code>def.dom</code> de 
+    détourner vers son serveur tout le trafic destiné à 
+    <code>abc.dom</code>. Pour ce faire, il doit simplement
+    positionner le champ DNS de <code>www.def.dom</code> sur 10.0.0.1, 
+    et rien ne peut l'empêcher de faire, puisqu'il a la main sur 
+    son DNS.</p>
+
+    <p>Les requêtes à destination de 10.0.0.1 (incluant celles dont 
+    l'URL contient <code>http://www.abc.com/tout_et_n_importe_quoi</code>) 
+    seront envoyées au serveur virtuel de <code>def.dom</code>. Une 
+    bonne compréhension des mécanismes internes d'Apache concernant 
+    la gestion des serveur virtuels est requise. 
+    <a href="vhosts/details.html">Ce document</a> explique ce 
+    fonctionnement.</p>
+  </section>
+
+  <section id="main">
+    <title>L'Adresse du "serveur principal"</title>
+
+    <p>L'implémentation du support des serveur virtuels <a 
+    href="vhosts/name-based.html">par nom</a> depuis Apache 1.1 suppose
+    qu'Apache connaisse la ou les adresse(s) IP sur lesquelles le serveur 
+    écoute. Pour déterminer cette adresse, Apache utilise soit la 
+    directive globale <directive module="core">ServerName</directive> 
+    (si elle est présente), soit un appel à la fonction C 
+    <code>gethostname</code> (cet appel renvoie le même résultat 
+    que la commande "hostname" entrée sur une ligne de commande). 
+    Une résolution DNS est alors effectuée sur l'adresse obtenue. 
+    Pour l'instant, il n'existe aucun moyen de contourner cette 
+    requête DNS.</p>
+
+    <p>Pour se prémunir du cas où cette résolution DNS échouerait à 
+    cause de la défaillance du serveur DNS, le nom d'hôte peut être 
+    ajouté dans <code>/etc/hosts</code> (il y est probablement déjà). 
+    Assurez vous que votre machine est configurée pour lire ce fichier 
+    <code>/etc/hosts</code> en cas de défaillance du serveur DNS. 
+    Pour cela, selon votre système d'exploitation, il vous faudra configurer 
+    <code>/etc/resolv.conf</code> ou <code>/etc/nsswitch.conf</code>.</p>
+
+    <p>Au cas où votre serveur n'a pas besoin de réaliser des requêtes 
+    DNS pour d'autres raisons que de démarrer Apache, il est possible 
+    que vous puissiez vous en sortir en positionnant la variable 
+    d'environnement <code>HOSTRESORDER</code> sur "local". Ceci dépend 
+    cependant de votre système d'exploitation et des librairies de 
+    résolution DNS que vous utilisez. Ceci affecte également le 
+    comportement des scripts CGIs, à moins que vous n'utilisiez 
+    <module>mod_env</module> pour contrôler leur environnement. La 
+    meilleure solution est de consulter les pages "man" ou les FAQs 
+    spécifiques à votre système d'exploitation.</p>
+  </section>
+
+  <section id="tips">
+    <title>Comment éviter ces problèmes</title>
+
+    <ul>
+      <li>
+        spécifier les adresses IP dans les 
+        <directive module="core">VirtualHost</directive>
+      </li>
+
+      <li>
+        spécifier les adresses IP au moyen de
+        <directive module="mpm_common">Listen</directive>
+      </li>
+
+      <li>
+        s'assurer que tous les serveurs virtuels spécifient explicitement 
+        leur <directive module="core">ServerName</directive>
+      </li>
+
+      <li>créer un serveur virtuel <code>&lt;VirtualHost _default_:*&gt;</code>
+      qui ne sert aucune page</li>
+    </ul>
+  </section>
+
+  <section id="appendix">
+    <title>Appendice: Perspectives futures</title>
+
+    <p>Les problèmes liés au DNS sont très indésirables. À partir 
+    d'Apache 1.2, nous avons travaillé à ce qu'Apache démarre même 
+    dans le cas où les requêtes DNS échouent, mais ce n'est pas 
+    forcément la meilleure des solutions. En tous cas, obliger 
+    l'administrateur à spécifier explicitement des adresses IP est 
+    également très indésirable sur le réseau Internet tel qu'il 
+    existe actuellement, où le nombre d'adresses IP commence à manquer.</p>
+    
+    <p>Une réponse possible au problème de vol de trafic décrit ci-avant
+    pourrait être de réaliser une résolution inverse DNS sur l'adresse IP 
+    renvoyée par la première requête, et de comparer les deux noms 
+    obtenus -- lorsqu'ils sont différents, le serveur virtuel serait 
+    désactivé. Ceci suppose que la configuration pour la résolution 
+    inverse DNS soit faite correctement (c'est une chose à laquelle 
+    les administrateurs DNS commencent à s'habituer, en raison de 
+    l'utilisation de plus en plus répandue des requêtes DNS 
+    "double-reverse" par les serveurs FTP et les filtrages 
+    "TCP wrappers").</p>
+    
+    <p>Dans tous les cas de figures, il ne semble pas possible de 
+    démarrer de façon fiable un serveur virtuel quand la requête 
+    DNS a échoué, à moins de recourir à l'utilisation d'adresses 
+    IP fixes. Des solutions partielles, telles que désactiver des 
+    portions de la configuration selon les tâches attribuées au 
+    serveur Web, risquent d'être pires que ne pas démarrer du tout.</p>
+    
+    <p>Au fur et à mesure que HTTP/1.1 se répand, et que les navigateurs 
+    et les serveurs mandataires envoient l'en-tête <code>Host</code>, 
+    il devient possible d'éviter complètement l'utilisation de serveurs 
+    virtuels par IP. Dans ce cas, les serveurs Web n'ont plus aucun 
+    besoin de réaliser des requêtes DNS lors de leur démarrage. Au 1er 
+    mars 1997, ces fonctionnalités ne sont pas suffisamment déployées pour 
+    que des serveurs Web sensibles les mettent en oeuvre (NdT&nbsp;: cette 
+    remarque est aujourd'hui complètement dépassée, HTTP/1.1 est 
+    désormais supporté par l'immense majorité des navigateurs et 
+    des serveurs mandataires).</p>
+  </section>
+</manualpage>

Propchange: httpd/httpd/branches/2.0.x/docs/manual/dns-caveats.xml.fr
------------------------------------------------------------------------------
    svn:eol-style = native

Added: httpd/httpd/branches/2.0.x/docs/manual/dso.xml.fr
URL: http://svn.apache.org/viewcvs/httpd/httpd/branches/2.0.x/docs/manual/dso.xml.fr?view=auto&rev=155795
==============================================================================
--- httpd/httpd/branches/2.0.x/docs/manual/dso.xml.fr (added)
+++ httpd/httpd/branches/2.0.x/docs/manual/dso.xml.fr Tue Mar  1 07:52:13 2005
@@ -0,0 +1,314 @@
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
+<!-- English Revision: 151405 -->
+<!-- French Translation by Vincent Deffontaines, review by alain B -->
+
+<!--
+ Copyright 2005 The Apache Software Foundation or its licensors, as
+ applicable.
+
+ Licensed 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.
+-->
+
+<manualpage metafile="dso.xml.meta">
+
+  <title>Support des objets partagés dynamiques (DSO)</title>
+
+  <summary>
+    <p>Le serveur HTTP Apache est un programme modulaire permettant à
+    l'administrateur de choisir les fonctionnalités qu'il souhaite 
+    activer, au moyen de modules. Les modules peuvent être intégrés
+    dans le programme binaire <code>httpd</code> au moment de la 
+    compilation. Il est également possible de compiler à part des 
+    modules en tant qu'objets dynamiques partagés (Dynamic Shared 
+    Objects&nbsp;: DSOs) existant séparément du fichier binaire principal 
+    <code>httpd</code>. Les modules DSO peuvent être compilés en même 
+    temps que le serveur, ou après, au moyen de l'outil Apache pour 
+    les extensions (<program>apxs</program>).</p>
+
+    <p>Ce document décrit les principes de fonctionnement des modules DSO, et
+    montre comment les utiliser.</p>
+  </summary>
+
+
+<section id="implementation"><title>Implémentation</title>
+
+<related>
+<modulelist>
+<module>mod_so</module>
+</modulelist>
+<directivelist>
+<directive module="mod_so">LoadModule</directive>
+</directivelist>
+</related>
+
+    <p>Le support DSO servant à charger des modules Apache, est lui-même 
+    codé dans un module, nommé <module>mod_so</module>, qui doit être 
+    compilé dans le noyau d'Apache. Ce module, ainsi que le module 
+    <module>core</module>, sont les deux seuls modules qui ne peuvent 
+    être compilés séparément d'Apache. En pratique, tous les autres 
+    modules d'Apache peuvent être compilés en tant que modules DSO, 
+    en passant au script <code>configure</code> l'option 
+    <code>--enable-<em>module</em>=shared</code>, comme précisé dans 
+    la <a href="install.html">documentation d'installation</a>. Après 
+    qu'un module ait été compilé en DSO (nommé 
+    <code>mod_monmodule.so</code>), il est possible d'utiliser la 
+    directive de <module>mod_so</module>&nbsp;: <directive module="mod_so"
+    >LoadModule</directive> dans le fichier <code>httpd.conf</code>, 
+    afin qu'Apache charge ledit module au démarrage ou redémarrage du 
+    serveur.</p>
+
+    <p>Afin de simplifier la création de fichiers DSO pour les 
+    modules Apache (et en particulier les modules tiers), un nouveau 
+    programme de support a été ajouté&nbsp;: <a href="programs/apxs.html"
+    >apxs</a> (<em>APache eXtenSion</em>). Ce programme peut être 
+    utilisé pour créer des modules DSO <em>en se passant de</em> 
+    l'arborescence source d'Apache. L'idée en est simple&nbsp;: lors de 
+    l'installation d'Apache, la commande <code>make install</code> 
+    positionne les fichiers d'en-têtes C d'Apache, ainsi que les 
+    options du compilateur et les options propres à la plate-forme 
+    dans le programme <code>apxs</code>. Ceci permet à l'utilisateur 
+    de compiler ses modules Apache, au moyen de <code>apxs</code>, 
+    sans disposer de l'arborescence source d'Apache et sans devoir 
+    manipuler les options de compilation ou les options propres à 
+    sa plate-forme.</p>
+</section>
+
+<section id="usage"><title>Résumé sur l'utilisation des DSO</title>
+
+    <p>Voici un résumé bref des fonctionnalités DSO d'Apache 2.0&nbsp;:</p>
+
+    <ol>
+      <li>
+        Pour compiler et installer un module Apache <em>distribué 
+        avec Apache</em>, par exemple <code>mod_foo.c</code>, en tant 
+        que DSO, sous le nom <code>mod_foo.so</code>&nbsp;:
+
+<example>
+$ ./configure --prefix=/path/to/install --enable-foo=shared<br />
+$ make install
+</example>
+      </li>
+
+      <li>
+        Pour compiler et installer un module Apache <em>fourni par un 
+        tiers</em>, par exemple <code>mod_foo.c</code>, en tant que DSO, 
+        sous le nom <code>mod_foo.so</code>&nbsp;:
+
+<example>
+$ ./configure --add-module=module_type:/chemin/vers/le/tiers/mod_foo.c --enable-foo=shared<br />
+$ make install
+</example>
+      </li>
+
+      <li>
+        Pour configurer Apache afin qu'il puisse accepter les modules DSO&nbsp;:
+
+<example>
+$ ./configure --enable-so<br />
+$ make install
+</example>
+      </li>
+
+      <li>
+        Pour compiler et installer un module Apache <em>fourni par un 
+        tiers</em>, par exemple <code>mod_foo.c</code>, en tant que 
+        DSO, et sans disposer de l'arborescence source d'Apache 
+        (utilisation d'<a href="programs/apxs.html">apxs</a>)&nbsp;:
+
+<example>
+$ cd /chemin/vers/le/tiers<br />
+$ apxs -c mod_foo.c<br />
+$ apxs -i -a -n foo mod_foo.la
+</example>
+      </li>
+    </ol>
+
+    <p>Dans tous les cas, une fois qu'un module a été compilé en tant 
+    que DSO, vous devrez utiliser la directive 
+    <directive module="mod_so">LoadModule</directive> dans le 
+    fichier <code>httpd.conf</code> afin qu'Apache active le module.</p>
+</section>
+
+<section id="background"><title>Contexte</title>
+
+    <p>Sur les systèmes récents, dérivés d'Unix, il existe un procédé 
+    élégant, habituellement appelé chargement dynamique d'objets 
+    partagés DSO,  permettant de compiler un morceau de code sous un 
+    format spécial, et de pouvoir le charger en temps réel dans 
+    l'espace d'adressage d'un programme exécutable.</p>
+    
+    <p>Ce chargement peut être réalisé de deux manières&nbsp;: 
+    automatiquement, grâce à un programme système nommé <code>ld.so</code> 
+    lors du démarrage d'un exécutable, ou manuellement depuis un programme 
+    en exécution via une interface programmée au moyen des appels 
+    systèmes <code>dlopen()/dlsym()</code> du "chargeur" Unix</p>
+    
+    <p>Dans le premier cas, il est courant d'appeler les DSO des 
+    <em>bibliothèques partagées</em> ou des <em>bibliothèques DSO</em>&nbsp;; 
+    on les nomme <code>libfoo.so</code> ou <code>libfoo.so.1.2</code>. 
+    Elles sont toutes placées dans un répertoire système (souvent 
+    <code>/usr/lib</code>) et sont liées par les programmes exécutables 
+    lors de la compilation de ces derniers, en précisant au moment de 
+    la compilation l'option <code>-lfoo</code> à la commande de link 
+    (linker command). Cette manière de procéder insère les références 
+    des bibliothèques dans le coeur des programmes, afin qu'au moment 
+    du démarrage du programme, le "chargeur" Unix puisse trouver 
+    <code>libfoo.so</code> dans <code>/usr/lib</code>, ou bien dans 
+    les chemins codés en dur au moyen de l'option de link <code>-R</code>, 
+    ou dans un chemin configuré au moyen de la variable d'environnement 
+    <code>LD_LIBRARY_PATH</code>. Tous les symboles non résolus présents 
+    dans le programme sont alors résolus au moyen de DSO.</p>
+
+    <p>Les symboles propres au programme exécutable ne sont généralement 
+    pas référencés par le DSO (puisque c'est une bibliothèque de code 
+    générique), et donc aucune résolution ne doit être suivie au delà 
+    de ce point. Le programme exécutable n'a pas de travail particulier 
+    à faire pour résoudre les symboles des DSO, puisque c'est le 
+    "chargeur" Unix qui s'occupe de cette tâche. (En réalité, le code 
+    utilisé pour invoquer <code>ld.so</code> fait partie du code de 
+    démarrage run-time, qui est lié à chaque programme exécutable 
+    non statique). L'avantage du chargement dynamique des bibliothèques 
+    de code générique est évident&nbsp;: le code n'est conservé qu'à un seul 
+    endroit du disque, dans une bibliothèque système comme 
+    <code>libc.so</code>, ce qui permet de gagner de l'espace disque 
+    pour chaque programme.</p>
+
+    <p>Dans le second cas, les DSO sont appelés <em>objets partagés</em> 
+    ou <em>fichiers DSO</em> et on peut leur attribuer une extension au 
+    choix (bien que leur nom soit habituellement <code>foo.so</code>). 
+    Ces fichiers résident normalement dans un répertoire propre au 
+    programme qui les utilise, et ils ne sont pas liés de manière 
+    automatique au programme qui les appelle. Celui-ci les charge en 
+    temps réel lors de son exécution, au moyen de <code>dlopen()</code>. 
+    À cet instant, aucune résolution des symboles du DSO n'est réalisée. 
+    C'est le "chargeur" Unix qui réalise la tâche de résoudre les 
+    symboles non résolus du DSO, à partir du jeu de symboles exportés 
+    par le programme et ses bibliothèques DSO (en particulier, tous 
+    les symboles de l'omniprésente <code>libc.so</code>). Ainsi, le DSO 
+    gagne la connaissance des symboles du programme exécutable, comme 
+    s'il lui avait été lié statiquement au départ.</p>
+    
+    <p>Enfin, pour tirer parti de l'API DSO, l'exécutable doit résoudre 
+    les symboles propres au DSO via <code>dlsym()</code>, pour les 
+    utiliser plus tard dans les tables de répartition (NdT&nbsp;: "dispatch 
+    tables"), <em>etc.</em> En d'autres termes, le programme exécutable 
+    doit résoudre lui-même chaque symbole pour utiliser chacun d'entre 
+    eux. L'avantage de ce mécanisme est que les parties optionnelles 
+    d'un programme ne sont pas chargées (et donc, n'encombrent pas la 
+    mémoire) avant que le programme n'en ait effectivement besoin. 
+    Quand elles deviennent nécessaires, ces parties du programme peuvent 
+    être chargées dynamiquement pour étendre les fonctionnalités du 
+    programme.</p>
+
+    <p>Bien que ce fonctionnement de DSO puisse paraître simple à 
+    comprendre, il existe au moins une difficulté d'implémentation&nbsp;: 
+    permettre au DSO de résoudre les symboles du programme quand un DSO 
+    est utilisé pour étendre un programme. Pourquoi cela&nbsp;? Parce que la 
+    "résolution à l'envers" des symboles DSO à partir des symboles du 
+    programme exécutable est contraire au principe de conception des 
+    bibliothèques (où, rappelons-le, la bibliothèque ne sait rien du 
+    programme qui l'utilise)&nbsp;; cette "résolution à l'envers" n'est pas 
+    standardisée, et n'existe pas sur toutes les plates-formes. En 
+    pratique, les symboles globaux d'un programme exécutable ne sont 
+    que rarement réexportés vers un DSO, et donc ne sont pas accessibles. 
+    Celui qui veut pouvoir étendre les fonctionnalités d'un programme 
+    dynamiquement, lors de l'exécution, doit trouver un moyen de forcer 
+    le programme de liaison à exporter tous les symboles globaux de ce 
+    programme.</p>
+
+    <p>L'approche par bibliothèques partagées est de loin la plus courante
+    parce que c'est celle pour laquelle les mécanismes DSO ont été conçus&nbsp;; 
+    elle est donc utilisée par presque toutes les bibliothèques du système
+    d'exploitation. De l'autre coté, l'utilisation des objets partagés reste 
+    une approche marginale.</p>
+    
+    <p>Depuis 1998, seules quelques solutions logiciels existantes 
+    utilisent le mécanisme des DSO pour étendre leurs fonctionnalités 
+    en cours exécution&nbsp;: Perl 5 (via son "XS mechanism" et le module 
+    DynaLoader), Netscape Server, <em>etc.</em> Depuis la version 1.3, 
+    Apache a rejoint ce groupe, car Apache utilise une approche 
+    modulaire pour étendre ses fonctionnalités, et utilise de manière 
+    interne des mécanismes de répartition par liste pour lier des 
+    modules externes à son noyau. Apache était vraiment prédestiné, 
+    par concept, à utiliser les DSO pour charger ses modules en temps 
+    réel.</p>
+</section>
+
+<section id="advantages"><title>Avantages et Inconvénients</title>
+
+    <p>Les possibilités des DSO décrites ci-avant présentent les
+    avantages suivants&nbsp;:</p>
+
+    <ul>
+      <li>Le paquetage du serveur est plus flexible lors de son exécution, 
+      car les processus du serveur central peuvent être étendus pendant 
+      son exécution, au moyen de la directive 
+      <directive module="mod_so">LoadModule</directive>, dans 
+      <code>httpd.conf</code>, plutôt que forcer les utilisateurs à 
+      recompiler le serveur pour modifier ses fonctionnalités. Par 
+      exemple, ce mode de fonctionnement permet de faire tourner 
+      plusieurs instances du serveur (version standard &amp; SSL 
+      version, version minimaliste &amp; étendue [mod_perl, PHP3], 
+      <em>etc.</em>) au moyen d'une seule installation d'Apache.</li>
+
+      <li>Il est très facile d'étendre les fonctionnalités du serveur 
+      de base, même après son installation. Ceci est d'un grand secours 
+      aux mainteneurs des paquets qui peuvent facilement créer des 
+      paquets pour l'installation de base d'Apache et d'autres paquets 
+      différents pour les extensions, comme PHP3, mod_perl, 
+      mod_fastcgi, <em>etc.</em></li>
+
+      <li>Facilité de développement des modules Apache&nbsp;; grâce aux outils
+      DSO/<code>apxs</code>, ce travail est faisable sans l'arborescence 
+      source d'Apache, et ne nécessite qu'une commande <code>apxs -i</code> 
+      suivi d'un <code>apachectl restart</code> pour ajouter au serveur 
+      déjà en marche les fonctionnalités du module développé.</li>
+    </ul>
+
+    <p>Les inconvénients liés à l'utilisation des DSO&nbsp;:</p>
+
+    <ul>
+      <li>Les mécanismes de DSO ne sont pas portables sur toutes les
+      plates-formes, car tous les systèmes d'exploitation ne supportent 
+      pas le chargement dynamique de code dans l'espace d'adressage d'un 
+      programme en marche.</li>
+
+      <li>Le serveur est à peu prêt 20% plus lent au démarrage, à cause de la
+      charge prise par le "chargeur" Unix de la résolution des symboles.</li>
+
+      <li>Le serveur est à peu prêt 5% plus lent en fonctionnement sur 
+      certaines plates-formes parce que le code indépendant de la 
+      position ("position independent code" - PIC) requiert parfois des 
+      tours de passe-passe en assembleur pour l'adressage relatif, ce qui 
+      n'est pas toujours aussi rapide que l'adressage absolu.</li>
+
+      <li>Les modules DSO ne pouvant pas être liés à d'autres bibliothèques 
+      DSO (<code>ld -lfoo</code>) sur toutes les plates-formes (par 
+      exemple, les plates-formes basées sur a.out ne le permettent pas, 
+      alors que celles basées sur ELF le permettent), il n'est pas possible
+      d'utiliser les mécanismes de DSO pour tous les modules. En d'autres
+      termes, les modules compilés en tant que fichiers DSO sont limités 
+      à l'utilisation des symboles exportés par le noyau d'Apache, par 
+      la bibliothèque C (<code>libc</code>) et toute autre bibliothèque 
+      dynamique ou statique utilisée par le noyau d'Apache, ou par des 
+      archives de bibliothèques statiques (<code>libfoo.a</code>) qui 
+      contiennent du code indépendant de la position. Les seuls moyens 
+      d'utiliser du code à l'extérieur d'un fichier DSO sont, soit de 
+      s'assurer que le noyau d'Apache contienne une référence vers ce 
+      code, soit de charger ce code au moyen de <code>dlopen()</code>.</li>
+    </ul>
+
+</section>
+</manualpage>

Propchange: httpd/httpd/branches/2.0.x/docs/manual/dso.xml.fr
------------------------------------------------------------------------------
    svn:eol-style = native

Added: httpd/httpd/branches/2.0.x/docs/manual/env.xml.fr
URL: http://svn.apache.org/viewcvs/httpd/httpd/branches/2.0.x/docs/manual/env.xml.fr?view=auto&rev=155795
==============================================================================
--- httpd/httpd/branches/2.0.x/docs/manual/env.xml.fr (added)
+++ httpd/httpd/branches/2.0.x/docs/manual/env.xml.fr Tue Mar  1 07:52:13 2005
@@ -0,0 +1,450 @@
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
+<!-- English Revision: 151405 -->
+<!-- French Translation by Vincent Deffontaines, review by alain B -->
+
+<!--
+ Copyright 2005 The Apache Software Foundation or its licensors, as
+ applicable.
+
+ Licensed 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.
+-->
+
+<manualpage metafile="env.xml.meta">
+
+  <title>Apache et les variables d'environnement</title>
+
+  <summary>
+    <p>Le serveur HTTP Apache permet de conserver et d'utiliser 
+    certaines informations dans des variables appelées <em>variables 
+    d'environnement</em>. Ces informations peuvent servir à contrôler 
+    divers paramètres tels que la journalisation ou le contrôle d'accès. 
+    Ces variables sont également utilisées pour communiquer avec d'autres 
+    programmes, comme les scripts CGI. Ce document traite des manières 
+    de manipuler et de tirer parti de ces variables.</p>
+
+    <p>Bien qu'elles soient appelées <em>variables d'environnement</em>, 
+    il ne s'agit pas de variables d'environnement contrôlées par le 
+    système d'exploitation. Ces variables sont conservées, et manipulées 
+    suivant des mécanismes internes à Apache. Elles sont transformées 
+    en véritables variables d'environnement (au sens système) seulement 
+    quand elles doivent être passées à des scripts CGI ou à des scripts 
+    'Server Side Includes'. Pour manipuler l'environnement du système 
+    d'exploitation sur lequel tourne un serveur Apache, il suffit 
+    d'utiliser les méthodes standard fournies par l'interpréteur de 
+    commandes du système d'exploitation.</p>
+  </summary>
+
+  <section id="setting">
+    <title>Définir les variables d'environnement</title>
+    <related>
+      <modulelist>
+        <module>mod_env</module>
+        <module>mod_rewrite</module>
+        <module>mod_setenvif</module>
+        <module>mod_unique_id</module>
+      </modulelist>
+      <directivelist>
+        <directive module="mod_setenvif">BrowserMatch</directive>
+        <directive module="mod_setenvif">BrowserMatchNoCase</directive>
+        <directive module="mod_env">PassEnv</directive>
+        <directive module="mod_rewrite">RewriteRule</directive>
+        <directive module="mod_env">SetEnv</directive>
+        <directive module="mod_setenvif">SetEnvIf</directive>
+        <directive module="mod_setenvif">SetEnvIfNoCase</directive>
+        <directive module="mod_env">UnsetEnv</directive>
+      </directivelist>
+    </related>
+
+    <section id="basic-manipulation">
+        <title>Manipulations simples de l'environnement</title>
+
+        <p>La méthode la plus simple pour définir une variable 
+        d'environnement dans Apache est d'utiliser la directive 
+        <directive module="mod_env" >SetEnv</directive>. Les variables 
+        peuvent également être chargées depuis l'interpréteur de 
+        commandes à partir duquel le serveur a été démarré, au moyen 
+        de la directive <directive module="mod_env">PassEnv</directive>.</p>
+        
+    </section>
+    <section id="conditional">
+        <title>Paramétrage selon les requêtes</title>
+
+        <p>Dans un but de souplesse, les directives que mod_setenvif 
+        permet d'utiliser sont ajustables en fonction de certaines 
+        caractéristiques des requêtes parvenant au serveur. Par exemple, 
+        il est possible de définir une variable seulement si la requête 
+        provient d'un certain type de navigateur (User-Agent), ou bien 
+        si un champ Referer bien précis est trouvé. Une souplesse encore 
+        plus grande est offerte par la directive 
+        <directive module="mod_rewrite">RewriteRule</directive> du 
+        module mod_rewrite qui accepte le paramètre <code>[E=...]
+        </code> pour définir des variables d'environnement.</p>
+
+    </section>
+    <section id="unique-identifiers">
+        <title>Identifiants uniques</title>
+
+        <p>Enfin, la variable d'environnement <code>UNIQUE_ID</code> 
+        est créée par mod_unique_id pour chaque requête, de manière à 
+        être unique et donc représentative de chaque requête.</p>
+
+    </section>
+    <section id="standard-cgi">
+        <title>Variables CGI standard</title>
+
+        <p>En plus de toutes les variables d'environnement définies dans 
+        la configuration d'Apache et celles du système d'exploitation, 
+        les <a href="http://cgi-spec.golux.com/">spécifications 
+        CGI</a> demandent que certaines variables d'environnement 
+        contenant des informations propres à la requête soient toujours 
+        passées aux scripts CGI et aux pages SSI.</p>
+
+    </section>
+    <section id="caveats">
+        <title>Problèmes possibles</title>
+
+        <ul>
+          <li>Il n'est pas possible de remplacer la valeur des variables 
+          CGI standard au moyen des directives qui manipulent les 
+          variables d'environnement.</li>
+
+          <li>Dans les cas où les scripts CGI sont lancés au moyen de 
+          <a href="suexec.html">suexec</a>, l'environnement est nettoyé et 
+          les variables sont initialisées avec des valeurs <em>sûres</em>, 
+          définies lors de la compilation de <code>suexec.c</code>.</li>
+
+          <li>Pour des raisons d'interopérabilité, les noms des variables 
+          d'environnement ne peuvent être constitués que de lettres, de 
+          chiffres et du caractère de soulignement '_'. De plus, le 
+          premier caractère du nom ne peut pas être un chiffre. Les 
+          caractères en contradiction avec ces règles sont remplacés par 
+          des caractères de soulignement avant que les variables ne 
+          soient transmises aux scripts CGI ou aux pages SSI.</li>
+        </ul>
+    </section>
+  </section>
+  <section id="using">
+    <title>Utilisation des variables d'environnement</title>
+
+    <related>
+      <modulelist>
+        <module>mod_access</module>
+        <module>mod_cgi</module>
+        <module>mod_ext_filter</module>
+        <module>mod_headers</module>
+        <module>mod_include</module>
+        <module>mod_log_config</module>
+        <module>mod_rewrite</module>
+      </modulelist>
+      <directivelist>
+        <directive module="mod_access">Allow</directive>
+        <directive module="mod_log_config">CustomLog</directive>
+        <directive module="mod_access">Deny</directive>
+        <directive module="mod_ext_filter">ExtFilterDefine</directive>
+        <directive module="mod_headers">Header</directive>
+        <directive module="mod_log_config">LogFormat</directive>
+        <directive module="mod_rewrite">RewriteCond</directive>
+        <directive module="mod_rewrite">RewriteRule</directive>
+      </directivelist>
+    </related>
+
+    <section id="cgi-scripts">
+        <title>Scripts CGI</title>
+
+        <p>Une des principales utilisations des variables d'environnement 
+        est l'envoi d'informations aux scripts CGI. Comme précisé ci-
+        avant, l'environnement passé aux scripts CGI contient des 
+        informations standard au sujet de la requête en plus de toutes 
+        les variables initialisées au travers de la configuration 
+        d'Apache. Pour plus de détails, consultez le 
+        <a href="howto/cgi.html">tutorial CGI</a>.</p>
+
+    </section>
+    <section id="ssi-pages">
+        <title>Pages SSI</title>
+
+        <p>Les documents analysés par le serveur (documents SSI), gérés 
+        par le filtre <code>INCLUDES</code> de mod_include, peuvent 
+        demander l'affichage de variables d'environnement au moyen de 
+        l'élément <code>echo</code>, et peuvent les utiliser pour 
+        personnaliser des pages en fonctions de certaines caractéristiques 
+        de la requête. Apache permet aussi l'utilisation de pages SSI avec 
+        les variables d'environnement standard CGI comme discuté ci-avant. 
+        Consultez le <a href="howto/ssi.html">tutorial SSI</a> 
+        pour plus d'informations.</p>
+	
+    </section>
+    <section id="access-control">
+        <title>Contrôle d'accès</title>
+
+        <p>Les droits d'accès au serveur peuvent être contrôlés au moyen 
+        de variables d'environnement en utilisant les directives 
+        <code>allow from env=</code> et <code>deny from env=</code>. 
+        Celles ci, utilisées avec <directive module="mod_setenvif"
+        >SetEnvIf</directive>, permettent un contrôle d'accès au serveur 
+        très souple en fonction de caractéristiques propres au client. Par 
+        exemple, il est possible d'utiliser ces directives pour refuser 
+        l'accès au serveur à certains navigateurs (User-Agent).</p>
+
+    </section>
+    <section id="logging">
+        <title>Journalisation sous certaines conditions</title>
+
+        <p>Les variables d'environnement peuvent être enregistrées dans 
+        le journal des accès ('access log') au moyen de l'option 
+        <code>%e</code> de <directive module="mod_log_config"
+        >LogFormat</directive>. De plus, la décision d'enregistrer ou 
+        non certaines requêtes peut être prise en fonction des variables 
+        d'environnement au moyen de la directive 
+        <directive module="mod_log_config">CustomLog</directive>. Cette 
+        méthode, utilisée avec la directive <directive module="mod_setenvif"
+        >SetEnvIf</directive>, permet un contrôle très souple de 
+        l'enregistrement des requêtes. Par exemple, il est possible de 
+        ne pas garder de trace des requêtes demandant des noms de fichiers 
+        se terminant par <code>gif</code>, ou de n'enregistrer que les 
+        requêtes des clients situés hors du sous-réseau auquel appartient 
+        le serveur.</p>
+
+    </section>
+    <section id="response-headers">
+        <title>Personnaliser les en-têtes des réponses HTTP</title>
+
+        <p>La directive <directive module="mod_headers">Header</directive> 
+        peut tirer parti de l'existence ou non d'une variable 
+        d'environnement afin de choisir d'inclure certains en-têtes 
+        HTTP dans la réponse retournée au client. Ceci permet, par 
+        exemple, d'envoyer un certain en-tête de réponse seulement si un 
+        en-tête similaire a été positionné dans la requête émanant du 
+        client.</p>
+
+    </section>
+
+    <section id="external-filter">
+        <title>Activation des filtres externes</title>
+
+        <p>Il est possible d'utiliser une variable d'environnement pour 
+        activer les filtres externes (gérés par 
+        <module>mod_ext_filter</module> au moyen de la directive 
+        <directive module="mod_ext_filter">ExtFilterDefine</directive>) 
+        grâce aux options <code>disableenv=</code> et 
+        <code>enableenv=</code>.</p>
+    </section>
+
+    <section id="url-rewriting">
+        <title>Réécriture d'URL</title>
+
+        <p>La forme <code>%{ENV:...}</code> de <em>TestString</em>, dans 
+        la directive <directive module="mod_rewrite"
+        >RewriteCond</directive>, permet au moteur de réécriture de 
+        mod_rewrite d'utiliser les variables d'environnement pour 
+        contrôler les réécritures. Notez que toutes les variables 
+        internes à mod_rewrite, accessibles sans le préfixe 
+        <code>ENV:</code>, ne sont pas des variables d'environnement 
+        d'Apache. Elles sont uniquement propres à mod_rewrite et ne 
+        peuvent pas être utilisées par d'autres modules.</p>
+    </section>
+  </section>
+
+  <section id="special">
+    <title>Variables d'environnement spéciales</title>
+
+        <p>Certains problèmes liés à l'interopérabilité ont conduit à la 
+        mise en place de mécanismes spéciaux, qui modifient le 
+        fonctionnement d'Apache selon le type des clients auxquels il 
+        répond. Afin de garantir la plus grande souplesse possible, ces 
+        mécanismes sont contrôlés par des variables d'environnement 
+        spéciales, telles que <directive module="mod_setenvif"
+        >BrowserMatch</directive>, bien qu'on puisse également utiliser 
+        <directive module="mod_env">SetEnv</directive> et 
+        <directive module="mod_env">PassEnv</directive> par exemple.</p>
+	
+    <section id="downgrade">
+        <title>downgrade-1.0</title>
+
+        <p>Ceci oblige Apache à traiter la requête comme du HTTP/1.0 même 
+        si elle a été construite sur une norme plus récente.</p>
+
+    </section>
+    <section id="force-no-vary">
+        <title>force-no-vary</title>
+
+        <p>Ceci provoque l'effacement de tous les champs <code>Vary</code> 
+        de l'en-tête de réponse avant qu'il ne soit envoyé au client. 
+        Certains clients interprètent mal ce champ (voir 
+        <a href="misc/known_client_problems.html">les problèmes avec 
+        certains clients</a>), et initialiser cette variable peut 
+        permettre de résoudre ce problème. Cette variable requiert 
+        également l'utilisation de <strong>force-response-1.0</strong>.</p>
+
+    </section>
+    <section id="force-response">
+        <title>force-response-1.0</title>
+
+      <p>Ceci oblige Apache à n'envoyer que des réponses en HTTP/1.0 aux 
+      clients réalisant une requête en HTTP/1.0. Cette fonction a été 
+      implémentée au départ pour résoudre un problème avec les serveurs 
+      mandataires d'AOL. Certains clients HTTP/1.0 réagissent mal quand 
+      ils reçoivent une réponse en HTTP/1.1, ce qui peut poser des 
+      problèmes d'interopérabilité avec eux.</p>
+
+    </section>
+
+    <section id="gzip-only-text-html">
+        <title>gzip-only-text/html</title>
+
+        <p>Si cette variable est positionnée avec une valeur de "1", le 
+        filtre de sortie DEFLATE du module <module>mod_deflate</module> 
+        se retrouve désactivé pour les documents dont le type mime n'est 
+        pas <code>text/html</code>.</p>
+	
+    </section>
+
+    <section id="no-gzip"><title>no-gzip</title>
+
+        <p>Si cette variable est initialisée, le filtre <code>DEFLATE</code> 
+        du module <module>mod_deflate</module> est totalement désactivé.</p>
+
+    </section>
+
+    <section id="nokeepalive">
+        <title>nokeepalive</title>
+
+        <p>Si cette variable est initialisée, les fonctions 
+        <directive module="core">KeepAlive</directive> sont désactivées.</p>
+
+    </section>
+
+    <section id="prefer-language"><title>prefer-language</title>
+
+        <p>Cette variable modifie le fonctionnement de 
+        <module>mod_negotiation</module>. Si la variable contient un 
+        marqueur de langue (comme <code>en</code>, <code>ja</code> ou 
+        <code>x-klingon</code>), le module <module>mod_negotiation</module> 
+        va tenter de fournir une réponse dans cette langue parmi les 
+        variantes possibles. Si aucune de ces variantes n'existe, une 
+        <a href="content-negotiation.html">négociation</a> normale aura 
+        lieu.</p>
+
+    </section>
+
+    <section id="redirect-carefully">
+        <title>redirect-carefully</title>
+
+        <p>Cette variable rend le serveur plus attentif quand il doit 
+        envoyer une redirection au client. Cette variable est 
+        habituellement utilisée quand un client a un problème connu 
+        pour gérer les redirections. Cette variable a été implémentée 
+        pour pallier à un problème du logiciel WebFolders de Microsoft 
+        qui ne sait pas gérer correctement les redirections vers les 
+        répertoires via les méthodes DAV.</p>
+
+    </section>
+
+   <section id="suppress-error-charset">
+       <title>suppress-error-charset</title>
+
+    <p><em>Existe depuis la version 2.0.40</em></p>
+
+    <p>Quand Apache envoie une redirection en réponse à une requête, la 
+    réponse contient un message à afficher par le client, au cas où il 
+    ne peut suivre automatiquement la redirection. Le fonctionnement 
+    par défaut d'Apache est d'écrire ce texte avec le jeu de caractère 
+    qu'il utilise, c'est à dire ISO-8859-1.</p>
+    <p>Cependant, si la redirection pointe vers une page présentant un jeu 
+    de caractères différent, certains navigateurs buggés utilisent le jeu 
+    de caractères du texte de la redirection, au lieu de celui de la page 
+    qu'ils affichaient. De ce fait, un texte en grec serait mal affiché.</p>
+    <p>Si cette variable d'environnement est utilisée, Apache n'indiquera 
+    pas le jeu de caractère dans le texte de la redirection, ce qui permet 
+    à ces navigateurs d'afficher correctement la page de destination.</p>
+
+   </section>
+
+  </section>
+
+  <section id="examples">
+    <title>Exemples</title>
+
+    <section id="misbehaving">
+        <title>Modifier le fonctionnement d'un protocole pour les clients 
+        qui le gèrent mal</title>
+
+        <p>Il est conseillé de placer les lignes suivantes dans httpd.conf 
+        afin de gérer des problèmes connus de certains clients.</p>
+<example><pre>
+#
+# Les directives ci-après modifient le fonctionnement standard de HTTP.
+# La première directive désactive les fonctions keepalive pour les 
+# navigateurs disant s'appeler 'Netscape 2.x'
+# Il existe des problèmes connus avec ces navigateurs.
+# La deuxième directive gère Internet Explorer 4.0b2 de Microsoft qui
+# n'implémente pas correctement HTTP/1.1 et qui ne supporte pas les 
+# fonctions keepalive quand la réponse du serveur contient des codes 301 
+# ou 302 (redirections)
+#
+BrowserMatch "Mozilla/2" nokeepalive
+BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
+
+#
+# Les directives ci-dessous désactivent HTTP/1.1 pour les navigateurs qui 
+# violent les spécifications HTTP/1.0, en ne sachant pas analyser des 
+# réponses basiques en HTTP/1.1.
+#
+BrowserMatch "RealPlayer 4\.0" force-response-1.0
+BrowserMatch "Java/1\.0" force-response-1.0
+BrowserMatch "JDK/1\.0" force-response-1.0</pre></example>
+
+    </section>
+    <section id="no-img-log">
+        <title>Ne pas enregistrer les requêtes pour des images dans le 
+        journal des accès</title>
+
+        <p>Cet exemple montre comment ne pas enregistrer les requêtes à 
+        destination d'images dans le journal des accès. Il est facile 
+        de le modifier, pour limiter l'enregistrement à certains 
+        répertoires, ou pour des requêtes venant de machines précises.</p>
+    <example><pre>
+SetEnvIf Request_URI \.gif image-request
+SetEnvIf Request_URI \.jpg image-request
+SetEnvIf Request_URI \.png image-request
+CustomLog logs/access_log common env=!image-request</pre></example>
+
+    </section>
+    <section id="image-theft">
+        <title>Empêcher le «&nbsp;vol d'images&nbsp;»</title>
+
+        <p>Cet exemple montre comment empêcher le chargement d'images de 
+        votre serveur depuis des pages qui ne sont pas hébergées sur 
+        celui-ci. Cette configuration n'est pas conseillée, mais elle 
+        peut être utile dans certaines circonstances. Il est supposé ici 
+        que toutes les images sont stockées dans le répertoire 
+        /web/images.</p>
+    <example><pre>
+SetEnvIf Referer "^http://www.example.com/" local_referal
+# Autorise les navigateurs qui n'envoient pas de champ Referer
+SetEnvIf Referer "^$" local_referal
+&lt;Directory /web/images&gt;
+   Order Deny,Allow
+   Deny from all
+   Allow from env=local_referal
+&lt;/Directory&gt;</pre></example>
+
+        <p>Pour plus d'informations sur cette technique, consultez le 
+        tutorial ApacheToday «&nbsp;<a 
+        href="http://apachetoday.com/news_story.php3?ltsn=2000-06-14-002-01-PS"
+        >Keeping Your Images from Adorning Other Sites</a>&nbsp;».</p>
+    </section>
+  </section>
+</manualpage>

Propchange: httpd/httpd/branches/2.0.x/docs/manual/env.xml.fr
------------------------------------------------------------------------------
    svn:eol-style = native

Added: httpd/httpd/branches/2.0.x/docs/manual/filter.xml.fr
URL: http://svn.apache.org/viewcvs/httpd/httpd/branches/2.0.x/docs/manual/filter.xml.fr?view=auto&rev=155795
==============================================================================
--- httpd/httpd/branches/2.0.x/docs/manual/filter.xml.fr (added)
+++ httpd/httpd/branches/2.0.x/docs/manual/filter.xml.fr Tue Mar  1 07:52:13 2005
@@ -0,0 +1,92 @@
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
+<!-- English Revision: 151405 -->
+<!-- French Translation by Vincent Deffontaines, review by alain B -->
+
+<!--
+ Copyright 2005 The Apache Software Foundation or its licensors, as
+ applicable.
+
+ Licensed 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.
+-->
+
+<manualpage metafile="filter.xml.meta">
+
+  <title>Filtres</title>
+
+  <summary>
+    <p>Ce document explique le fonctionnement des filtres avec Apache.</p>
+  </summary>
+
+  <section id="filters">
+    <title>Filtres</title>
+    <related>
+      <modulelist>
+        <module>mod_deflate</module>
+        <module>mod_ext_filter</module>
+        <module>mod_include</module>
+      </modulelist>
+      <directivelist>
+        <directive module="mod_mime">AddInputFilter</directive>
+        <directive module="mod_mime">AddOutputFilter</directive>
+        <directive module="mod_mime">RemoveInputFilter</directive>
+        <directive module="mod_mime">RemoveOutputFilter</directive>
+        <directive module="mod_ext_filter">ExtFilterDefine</directive>
+        <directive module="mod_ext_filter">ExtFilterOptions</directive>
+        <directive module="core">SetInputFilter</directive>
+        <directive module="core">SetOutputFilter</directive>
+      </directivelist>
+    </related>
+
+    <p>On appelle <em>filtre</em> un processus qui s'applique aux 
+    données reçues ou envoyées par le serveur. Les <em>filtres en 
+    entrée (input filters)</em> servent à filtrer les données envoyées 
+    par les clients vers le serveur, tandis que les <em>filtres en sortie 
+    (output filters)</em> traitent les données envoyées par le 
+    serveur vers un client. Il est possible d'appliquer plusieurs 
+    filtres sur un flux de données, et l'ordre de ces filtres est 
+    configurable.</p>
+    
+    <p>Apache utilise des filtres en interne pour gérer les «&nbsp;grosses&nbsp;» 
+    requêtes ou les requêtes partielles (NdT sur "byte-range"&nbsp;: 
+    requêtes portant seulement sur une partie d'un fichier, partie 
+    spécifiée par un pointeur de départ, et un pointeur de fin). 
+    Certains modules permettent en plus d'utiliser des filtres en 
+    utilisant des directives de configuration. Les filtres sont utilisables 
+    au moyen des directives
+    <directive module="core">SetInputFilter</directive>,
+    <directive module="core">SetOutputFilter</directive>,
+    <directive module="mod_mime">AddInputFilter</directive>,
+    <directive module="mod_mime">AddOutputFilter</directive>,
+    <directive module="mod_mime">RemoveInputFilter</directive>, et
+    <directive module="mod_mime">RemoveOutputFilter</directive>
+    .</p>
+
+    <p>Les filtres listés ci-après sont fournis dans le paquetage Apache et
+    sont utilisables par tout administrateur.</p>
+
+    <dl>
+      <dt>INCLUDES</dt>
+      <dd>Gestion des "Server-Side Includes" grâce au module 
+      <module>mod_include</module></dd>
+      <dt>DEFLATE</dt>
+      <dd>Compression des données avant leur envoi au client (filtre en 
+      sortie) au moyen de <module>mod_deflate</module>
+      </dd>
+    </dl>
+
+    <p>Le module <module>mod_ext_filter</module> permet également 
+    d'utiliser des programmes externes à Apache en tant que filtres.</p>
+  </section>
+</manualpage>

Propchange: httpd/httpd/branches/2.0.x/docs/manual/filter.xml.fr
------------------------------------------------------------------------------
    svn:eol-style = native

Added: httpd/httpd/branches/2.0.x/docs/manual/handler.xml.fr
URL: http://svn.apache.org/viewcvs/httpd/httpd/branches/2.0.x/docs/manual/handler.xml.fr?view=auto&rev=155795
==============================================================================
--- httpd/httpd/branches/2.0.x/docs/manual/handler.xml.fr (added)
+++ httpd/httpd/branches/2.0.x/docs/manual/handler.xml.fr Tue Mar  1 07:52:13 2005
@@ -0,0 +1,167 @@
+<?xml version="1.0" encoding="ISO-8859-1" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
+<!-- English Revision: 151405 -->
+<!-- French Translation by Vincent Deffontaines, review by alain B -->
+
+<!--
+ Copyright 2005 The Apache Software Foundation or its licensors, as
+ applicable.
+
+ Licensed 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.
+-->
+
+<manualpage metafile="handler.xml.meta">
+
+  <title>Utilisation des gestionnaires apache</title>
+
+  <summary>
+    <p>Ce document décrit l'utilisation des gestionnaires (Handlers) Apache.</p>
+  </summary>
+
+  <section id="definition">
+    <title>Qu'est ce qu'un Gestionnaire&nbsp;?</title>
+    <related>
+      <modulelist>
+        <module>mod_actions</module>
+        <module>mod_asis</module>
+        <module>mod_cgi</module>
+        <module>mod_imap</module>
+        <module>mod_info</module>
+        <module>mod_mime</module>
+        <module>mod_negotiation</module>
+        <module>mod_status</module>
+     </modulelist>
+      <directivelist>
+        <directive module="mod_actions">Action</directive>
+        <directive module="mod_mime">AddHandler</directive>
+        <directive module="mod_mime">RemoveHandler</directive>
+        <directive module="core">SetHandler</directive>
+      </directivelist>
+    </related>
+
+
+    <p>Un Gestionnaire "handler" est une représentation interne à 
+    Apache, qui décrit quoi faire quand un fichier est appelé. De 
+    manière générale, les fichiers disposent d'un gestionnaire 
+    implicite en fonction de leurs types. Le fonctionnement standard 
+    est de simplement servir le fichier tel qu'il est demandé, mais 
+    certains types de fichiers peuvent être gérés différemment.</p>
+    
+    <p>Depuis Apache 1.1, il est possible de forcer l'utilisation 
+    des gestionnaires. Ils peuvent être spécifiés pour des fichiers 
+    présentant une certaine extension ou présents dans un certain 
+    répertoire, et peuvent être utilisés indépendamment des types 
+    des fichiers. Cette technique est avantageuse, d'abord parce 
+    que plus élégante, mais aussi parce qu'on peut ainsi associer 
+    un type de fichier <strong>et</strong> un gestionnaire à un 
+    fichier. (Voir aussi&nbsp;: <a href="mod/mod_mime.html#multipleext"
+    >Fichiers à Extensions Multiples</a>.)</p>
+
+    <p>Les gestionnaires peuvent être intégrés au serveur, ou inclus 
+    dans un module, ou encore être configurés au moyen de la directive 
+    <directive module="mod_actions">Action</directive>. Les 
+    gestionnaires fournis par défaut dans la distribution d'Apache 
+    se présentent comme suit&nbsp;:</p>
+
+    <ul>
+      <li><strong>default-handler</strong>&nbsp;: Envoie le fichier en 
+      utilisant <code>default_handler()</code> qui est le 
+      gestionnaire utilisé par défaut pour gérer les contenus 
+      statiques. (noyau d'Apache)</li>
+
+      <li><strong>send-as-is</strong>&nbsp;: Envoie le fichier avec les 
+      en-têtes HTTP tels quels. (<module>mod_asis</module>)</li>
+
+      <li><strong>cgi-script</strong>&nbsp;: Traite le fichier comme un 
+      script CGI. (<module>mod_cgi</module>)</li>
+
+      <li><strong>imap-file</strong>&nbsp;: Traite le fichier comme un 
+      ensemble de règles imagemap. NdT&nbsp;: ces fonctionnalités sont 
+      désuètes, et sont réalisées à présent coté client. 
+      (<module>mod_imap</module>)</li>
+
+      <li><strong>server-info</strong>&nbsp;: Envoie les informations 
+      de configuration du serveur. (<module>mod_info</module>)</li>
+
+      <li><strong>server-status</strong>&nbsp;: Envoie les informations sur 
+      le fonctionnement et la charge du serveur. 
+      (<module>mod_status</module>)</li>
+
+      <li><strong>type-map</strong>&nbsp;: Traite le fichier comme un 
+      fichier de types pour la négociation de contenu. 
+      (<module>mod_negotiation</module>)</li>
+    </ul>
+  </section>
+  <section id="examples">
+    <title>Exemples</title>
+
+    <section id="example1">
+      <title>Modifier un contenu statique au moyen d'un script CGI</title>
+
+      <p>Les directives ci-après provoquent l'exécution du script 
+      CGI <code>footer.pl</code> à chaque requête de fichier 
+      présentant l'extension <code>html</code>.</p>
+      
+      <example>
+        Action add-footer /cgi-bin/footer.pl<br/>
+        AddHandler add-footer .html
+      </example>
+
+      <p>Le travail du script CGI est alors d'envoyer le document 
+      demandé (désigné au moyen de la variable d'environnement 
+      <code>PATH_TRANSLATED</code>) en lui faisant subir au préalable 
+      les transformations désirées.</p>
+
+    </section>
+    <section id="example2">
+      <title>Fichiers contenant des en-têtes HTTP</title>
+
+      <p>Les directives ci-après activent le gestionnaire 
+      <code>send-as-is</code>, utilisé pour gérer les fichiers 
+      qui contiennent leurs propres en-têtes HTTP. Tous les fichiers 
+      contenus dans le répertoire <code>/web/htdocs/asis/</code> 
+      seront traités par le gestionnaire <code>send-as-is</code>, 
+      sans tenir compte de leurs extensions.</p>
+
+      <example>
+        &lt;Directory /web/htdocs/asis&gt;<br/>
+        SetHandler send-as-is<br/>
+        &lt;/Directory&gt;
+      </example>
+
+    </section>
+  </section>
+  <section id="programmer">
+    <title>Note aux programmeurs</title>
+
+    <p>L'<a href="developer/API.html">API d'Apache</a> a été modifiée 
+    lors de l'implémentation des gestionnaires&nbsp;; cette modification 
+    peut se révéler intéressante. Un nouvel enregistrement a été ajouté 
+    à la structure <code>request_rec</code>&nbsp;:</p>
+    
+    <example>
+      char *handler
+    </example>
+
+    <p>Pour qu'un module utilise un gestionnaire, il suffit d'affecter 
+    <code>r-&gt;handler</code> avec le nom du gestionnaire avant 
+    l'étape <code>invoke_handler</code> de la requête. Les 
+    gestionnaires fonctionnent comme auparavant, bien que leurs noms 
+    soient nécessaires au lieu d'un type de contenu. Bien qu'elle ne 
+    soit pas nécessaire, la convention de nommage des gestionnaires 
+    demande l'utilisation de mots séparés par des tirets, ne contenant 
+    aucun slash, afin de ne pas interférer avec l'espace de nommage 
+    des types de médias.</p>
+  </section>
+</manualpage>

Propchange: httpd/httpd/branches/2.0.x/docs/manual/handler.xml.fr
------------------------------------------------------------------------------
    svn:eol-style = native



Mime
View raw message