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]
