You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by nd...@apache.org on 2005/03/01 16:52:15 UTC
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
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 : 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>
+ <VirtualHost www.abc.dom> <br />
+ ServerAdmin webgirl@abc.dom <br />
+ DocumentRoot /www/abc <br />
+ </VirtualHost>
+ </example>
+
+ <p>Pour qu'Apache fonctionne correctement, il a absolument besoin
+ de deux informations pour chacun de ses serveurs virtuels :
+ <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 :</p>
+
+ <example>
+ <VirtualHost 10.0.0.1> <br />
+ ServerAdmin webgirl@abc.dom <br />
+ DocumentRoot /www/abc <br />
+ </VirtualHost>
+ </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 :</p>
+
+ <example>
+ <VirtualHost 10.0.0.1> <br />
+ ServerName www.abc.dom <br />
+ ServerAdmin webgirl@abc.dom <br />
+ DocumentRoot /www/abc <br />
+ </VirtualHost>
+ </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 ; 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 :</p>
+
+ <example>
+ <VirtualHost www.abc.dom> <br />
+ ServerAdmin webgirl@abc.dom <br />
+ DocumentRoot /www/abc <br />
+ </VirtualHost> <br />
+ <br />
+ <VirtualHost www.def.dom> <br />
+ ServerAdmin webguy@def.dom <br />
+ DocumentRoot /www/def <br />
+ </VirtualHost>
+ </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><VirtualHost _default_:*></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 : 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 : 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> : <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é : <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 : 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 :</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> :
+
+<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> :
+
+<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 :
+
+<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>) :
+
+<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 :
+ 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> ;
+ 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 : 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 : "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 :
+ permettre au DSO de résoudre les symboles du programme quand un DSO
+ est utilisé pour étendre un programme. Pourquoi cela ? 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) ; 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 ;
+ 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 : 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 :</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 & SSL
+ version, version minimaliste & é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 ; 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 :</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 « vol d'images »</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
+<Directory /web/images>
+ Order Deny,Allow
+ Deny from all
+ Allow from env=local_referal
+</Directory></pre></example>
+
+ <p>Pour plus d'informations sur cette technique, consultez le
+ tutorial ApacheToday « <a
+ href="http://apachetoday.com/news_story.php3?ltsn=2000-06-14-002-01-PS"
+ >Keeping Your Images from Adorning Other Sites</a> ».</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 « grosses »
+ requêtes ou les requêtes partielles (NdT sur "byte-range" :
+ 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 ?</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 : <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 :</p>
+
+ <ul>
+ <li><strong>default-handler</strong> : 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> : Envoie le fichier avec les
+ en-têtes HTTP tels quels. (<module>mod_asis</module>)</li>
+
+ <li><strong>cgi-script</strong> : Traite le fichier comme un
+ script CGI. (<module>mod_cgi</module>)</li>
+
+ <li><strong>imap-file</strong> : Traite le fichier comme un
+ ensemble de règles imagemap. NdT : 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> : Envoie les informations
+ de configuration du serveur. (<module>mod_info</module>)</li>
+
+ <li><strong>server-status</strong> : Envoie les informations sur
+ le fonctionnement et la charge du serveur.
+ (<module>mod_status</module>)</li>
+
+ <li><strong>type-map</strong> : 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>
+ <Directory /web/htdocs/asis><br/>
+ SetHandler send-as-is<br/>
+ </Directory>
+ </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 ; cette modification
+ peut se révéler intéressante. Un nouvel enregistrement a été ajouté
+ à la structure <code>request_rec</code> :</p>
+
+ <example>
+ char *handler
+ </example>
+
+ <p>Pour qu'un module utilise un gestionnaire, il suffit d'affecter
+ <code>r->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