Here is a .tar.gz with [some] translated docs. Most of the "base" is already translated. http://www.inl.fr/apache-docs.tar.gz
Vincent
Hello, Here are another reviewed files.
Doc 2.0 - Folder : manual/
--Alain
<?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 [EMAIL PROTECTED] <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 [EMAIL PROTECTED] <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 [EMAIL PROTECTED] <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 [EMAIL PROTECTED] <br />
DocumentRoot /www/abc <br />
</VirtualHost> <br />
<br />
<VirtualHost www.def.dom> <br />
ServerAdmin [EMAIL PROTECTED] <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>
<?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>
<a href="programs/apxs.html">apxs</a></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>
<?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>
<?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>
<?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>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
