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
And here are some others reviewed files. They're been review by me and Jean-Fran�ois El Fouly too.
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 2002-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="custom-error.xml.meta">
<title>Personnalisation des Messages d'Erreurs</title>
<summary>
<p>Il est possible � un administrateur Apache de configurer les r�ponses
d'Apache dans les cas o� des erreurs ou probl�mes se pr�sentent.</p>
<p>Des r�ponses param�trables peuvent �tre d�finies pour �tre activ�es au
cas o� le serveur d�tecterait une erreur ou un probl�me.</p>
<p>Quand un script plante et g�n�re une r�ponse "500 Server Error", sa
r�ponse peut �tre remplac�e par un message plus convivial, ou par une
redirection vers une autre URL (locale, ou sur un autre serveur).</p>
</summary>
<section id="behavior">
<title>Fonctionnement</title>
<section>
<title>Fonctionnement ant�rieur</title>
<p>NCSA httpd 1.3 renvoyait un message d'erreur insipide qui ne
pr�sentait le plus souvent aucun sens ni � l'utilisateur, ni
dans les journaux d'enregistrement sur des sympt�mes causant
le plantage.</p>
</section>
<section>
<title>Fonctionnement des versions plus r�centes</title>
<p>Le serveur peut �tre param�tr� pour�:</p>
<ol>
<li>Afficher un autre message que celui cod� dans NCSA, ou bien</li>
<li>proc�der � une redirection sur une URL locale, ou bien</li>
<li>proc�der � une redirection vers un autre serveur.</li>
</ol>
<p>La redirection vers une autre URL peut �tre utile, mais seulement
si des informations peuvent �tre envoy�es pour expliquer/enregistrer
l'erreur ou le probl�me plus clairement.</p>
<p>Pour y parvenir, Apache d�finit de nouvelles variables
d'environnement CGI�:</p>
<example>
REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap,
image/jpeg<br />
REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX A.09.05
9000/712)<br />
REDIRECT_PATH=.:/bin:/usr/local/bin:/etc<br />
REDIRECT_QUERY_STRING=<br />
REDIRECT_REMOTE_ADDR=121.345.78.123<br />
REDIRECT_REMOTE_HOST=ooh.ahhh.com<br />
REDIRECT_SERVER_NAME=crash.bang.edu<br />
REDIRECT_SERVER_PORT=80<br />
REDIRECT_SERVER_SOFTWARE=Apache/0.8.15<br />
REDIRECT_URL=/cgi-bin/buggy.pl
</example>
<p>Notez que le pr�fixe <code>REDIRECT_</code> est pr�sent pour toutes
ces variables d'environnement.</p>
<p>Au minimum, <code>REDIRECT_URL</code> et
<code>REDIRECT_QUERY_STRING</code> seront pass�es � la nouvelle
URL (en supposant qu'il s'agisse d'un script CGI ou d'un
include CGI). Les autres variables ne sont d�finies que si
elles existaient avant l'apparition du probl�me ou de l'erreur.
<strong>Aucune</strong> de ces variables ne sera
d�finie si votre directive <directive module="core">ErrorDocument</directive>
entra�ne une redirection vers un serveur <em>externe</em>�;
tout ce qui commence par <code>http:</code> est consid�r� comme
une redirection externe, y compris si cela pointe vers le
serveur local.</p>
</section>
</section>
<section id="configuration">
<title>Configuration</title>
<p>Il est possible d'utiliser la directive
<directive module="core">ErrorDocument</directive> dans les fichiers
.htaccess si <directive module="core">AllowOverride</directive> est
param�tr�e pour le permettre.</p>
<p>Voici quelques exemples�:</p>
<example>
ErrorDocument 500 /cgi-bin/crash-recover <br />
ErrorDocument 500 "Sorry, our script crashed. Oh dear" <br />
ErrorDocument 500 http://xxx/ <br />
ErrorDocument 404 /Lame_excuses/not_found.html <br />
ErrorDocument 401 /Subscription/how_to_subscribe.html
</example>
<p>La syntaxe � utiliser est�:</p>
<example>
ErrorDocument <code-�-3-chiffres> <action>
</example>
<p>o� l'action peut d�signer�:</p>
<ol>
<li>Un message � afficher. Le message doit �tre pr�c�d� par
des guillemets ("). Tout ce qui suit ces guillemets est affich�.
<em>Notez que le pr�fixe (") n'est pas affich�.</em></li>
<li>Une URL vers un serveur externe, vers lequel la redirection
sera effectu�e.</li>
<li>Une URL locale vers laquelle la redirection sera effectu�e.</li>
</ol>
</section>
<section id="custom">
<title>Messages d'Erreurs Personnalis�s et Redirections</title>
<p>Le fonctionnement d'Apache vis-�-vis des redirections a �t�
modifi� afin que les nouvelles variables d'environnement soient
disponibles pour un script ou un server-include.</p>
<section>
<title>Fonctionnement ant�rieur</title>
<p>Les variables CGI standard �taient pass�es au script sur
lequel pointe la redirection. Aucune indication sur la
provenance de la redirection n'�tait fournie.</p>
</section>
<section>
<title>Fonctionnement pour les nouvelles versions</title>
<p>Une s�rie de nouvelles variables d'environnement est
initialis�e pour �tre pass�e au script sur lequel pointe
la redirection. Chacune de ces variables est munie du pr�fixe
<code>REDIRECT_</code>. Les variables d'environnement
<code>REDIRECT_</code> sont cr��es � partir des variables
d'environnement "normales", telles qu'existant avant la
redirection, mais simplement renomm�es au moyen du pr�fixe
<code>REDIRECT_</code>�; ainsi par exemple <code>HTTP_USER_AGENT</code>
devient <code>REDIRECT_HTTP_USER_AGENT</code>. En plus de ces
nouvelles variables, Apache d�finit <code>REDIRECT_URL</code>
et <code>REDIRECT_status</code> pour aider le script �
comprendre d'o� il a �t� appel�. L'URL d'origine et l'URL
redirig�e sont toutes deux ajout�es dans le journal "access".</p>
<p>Si <code>ErrorDocument</code> pr�cise une redirection
locale vers un script CGI, ce script devrait inclure un
champ "<code>Status:</code>" dans son en-t�te de transmission
afin d'assurer que le client re�oive bien le code d'erreur et
puisse comprendre ce qui l'a caus�. Par exemple, un script
Perl ErrorDocument pourrait inclure quelque chose comme�:</p>
<example>
... <br />
print "Content-type: text/html\n"; <br />
printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"}; <br />
...
</example>
<p>Un script d�di� � la gestion d'une erreur donn�e,
telle que <code>404�Not�Found</code>, peut bien s�r
utiliser le code sp�cifique d'erreur et le texte associ�.</p>
<p>Notez que le script <em>doit</em> envoyer l'en-t�te
<code>Status:</code> appropri�e (comme par exemple
<code>302�Found</code>), si la r�ponse contient un en-t�te
<code>Location:</code> (pour g�n�rer la redirection cot� client).
Sans cet en-t�te <code>Status:</code>, <code>Location:</code> n'aura
pas d'effet.</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 2002-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="content-negotiation.xml.meta">
<title>N�gociation de Contenus</title>
<summary>
<p>Apache suit les sp�cifications HTTP/1.1 en ce qui concerne
les n�gociations de contenus. Il est ainsi possible d'utiliser
les informations fournies par le navigateur (pr�f�rences de langues,
jeu de caract�res, encodage et types de m�dias). Apache essaye
aussi d'optimiser les cas des navigateurs envoyant des
informations incompl�tes.</p>
<p>C'est le module <module>mod_negotiation</module> qui fournit
la n�gociation de contenus�; ce module est inclus dans Apache
par d�faut.</p>
</summary>
<section id="about"><title>� propos de la N�gociation de Contenus</title>
<p>Diff�rentes repr�sentations peuvent �tre utilis�es pour
communiquer une ressource. Par exemple, plusieurs langues peuvent
�tre disponibles, ou plusieurs types de m�dias, voire parfois une
combinaison de ces possibilit�s.
Une m�thode pour g�rer cela est de donner le choix au visiteur,
en lui proposant un index g�n�ral, qui lui permet par exemple de
choisir sa langue. Cependant, il est souvent possible de faire ce
choix de mani�re automatique car les navigateurs peuvent pr�ciser
avec leurs requ�tes, la repr�sentation qu'ils pr�f�rent recevoir. Par
exemple, un navigateur pourrait sp�cifier qu'il pr�f�re recevoir les
informations en fran�ais si elles sont disponibles, ou en anglais
dans le cas contraire. Ce type d'information est communiqu� par les
navigateurs, dans les en-t�tes de chaque requ�te. Un navigateur ne
demandant que des documents en fran�ais enverrait</p>
<example>Accept-Language: fr</example>
<p>Notez que cette pr�f�rence ne sera g�r�e par le serveur que
s'il existe un choix de langues du c�t� du serveur.</p>
<p>Voici un exemple plus complet, o� le navigateur est configur� pour
accepter le fran�ais et l'anglais, mais avec une pr�f�rence pour le
fran�ais, et pour accepter divers types de m�dias, en pr�f�rant le
HTML au texte brut, et en pr�f�rant le GIF ou le JPEG aux autres types
de m�dias (sans pour autant refuser ces derniers, le cas �ch�ant)�:</p>
<example>
Accept-Language: fr; q=1.0, en; q=0.5<br />
Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1
</example>
<p>Apache supporte les n�gociations de contenus 'g�r�s par
le serveur', telles que sp�cifi�es dans HTTP/1.1. Les en-t�tes
<code>Accept</code>, <code>Accept-Language</code>,
<code>Accept-Charset</code> et <code>Accept-Encoding</code>
sont g�r�s. Apache supporte �galement les n�gociations de
contenus 'transparentes', telles que d�finies dans les RFC
2295 et 2296. En revanche les fonctions de 'feature
negotiation' d�finies dans ces RFCs ne sont pas support�es.</p>
<p>On appelle <strong>ressource</strong> une entit� conceptuelle
identifi�e par un URI (RFC 2396). Le travail d'un serveur HTTP,
tel Apache, est de donner un acc�s � des
<strong>repr�sentations</strong> des ressources � sa disposition,
chaque repr�sentation �tant envoy�e sous la forme d'une s�quence
d'octets d�finie selon un type de m�dia, un jeu de caract�res,
un encodage, etc. � tout moment, chaque ressource est associ�e
� z�ro, une ou plusieurs repr�sentations. Si plusieurs repr�sentations
sont disponibles pour une ressource, on dit que cette derni�re est
<strong>n�gociable</strong> et chacune de ses repr�sentations
possibles est appel�e une <strong>variante</strong>.
Les diff�rentes possibilit�s de choisir les variantes d'une ressource
n�gociable sont appel�es <strong>dimensions</strong> de la
n�gociation.</p>
</section>
<section id="negotiation"><title>N�gociations avec Apache</title>
<p>Pour qu'Apache puisse proc�der � la n�gociation d'une ressource,
il faut qu'il dispose d'informations � propos de chacune des variantes.
Deux m�thodes sont possibles�:</p>
<ul>
<li>R�aliser une "Table de Types" (<em>c'est-�-dire</em>,
un fichier <code>*.var</code>) qui pr�cise explicitement les fichiers
d�finissant les variantes, ou</li>
<li>Utiliser une recherche 'MultiViews', m�thode par laquelle
le serveur r�alise une recherche par motifs implicites,
et choisit parmi les r�sultats.</li>
</ul>
<section id="type-map"><title>Utilisation d'une Table de Types (Type Map)</title>
<p>Une table de types est un document qui est associ� avec le
gestionnaire <code>type-map</code> (ou, dans les plus anciennes
versions d'Apache, le type mime <code>application/x-type-map</code>).
Notez que pour impl�menter cette m�thode, un 'handler' doit �tre
d�fini dans la configuration pour associer une extension de fichier �
<code>type-map</code>�; ce qui est g�n�ralement obtenu au moyen de</p>
<example>AddHandler type-map .var</example>
<p>dans le fichier de configuration du serveur.</p>
<p>Les fichiers de table de types portent g�n�ralement le nom de la
ressource qu'ils d�crivent, et contiennent une entr�e correspondant
� chaque variante possible�; ces entr�es sont constitu�es de lignes
au format d'en-t�tes HTTP. Les entr�es de deux variantes distinctes
sont � s�parer par des lignes vides. Il n'est pas permis d'utiliser
des lignes vides au sein d'une entr�e. Il est courant de placer en
d�but de fichier une entr�e pour l'entit� combin�e
dans son ensemble (bien que cela ne soit pas n�cessaire, et ignor�
par Apache). Un exemple de fichier de table est donn� en exemple
ci-apr�s. Le nom de ce fichier serait <code>foo.var</code>, puisque
le fichier d�crit une ressource appel�e <code>foo</code>.</p>
<example>
URI: foo<br />
<br />
URI: foo.en.html<br />
Content-type: text/html<br />
Content-language: en<br />
<br />
URI: foo.fr.de.html<br />
Content-type: text/html;charset=iso-8859-2<br />
Content-language: fr, de<br />
</example>
<p>Notez que les fichiers de table de types sont toujours
utilis�s en priorit� par Apache par rapport � l'extension du
nom du fichier, et ce m�me si l'option Multiviews est activ�e.
Des variantes pr�sentant des qualit�s in�gales peuvent �tre indiqu�es
au moyen du param�tre de type de m�dia�: "qs", comme dans le cas de
cette image (disponible en JPEG, GIF ou ASCII-art)�: </p>
<example>
URI: foo<br />
<br />
URI: foo.jpeg<br />
Content-type: image/jpeg; qs=0.8<br />
<br />
URI: foo.gif<br />
Content-type: image/gif; qs=0.5<br />
<br />
URI: foo.txt<br />
Content-type: text/plain; qs=0.01<br />
</example>
<p>Les valeurs de qs acceptables sont comprises entre 0.000
et 1.000. Notez qu'une variante avec un qs de 0.000 ne sera
jamais choisie. La valeur de qs par d�faut est de 1.0. Le
param�tre qs sert � indiquer la qualit� de la variante, par
rapport aux autres variantes disponibles, et ce ind�pendamment
des possibilit�s du navigateur. Par exemple, un fichier JPEG
est g�n�ralement de meilleure qualit� qu'un fichier ASCII, si
les 2 documents sont destin�s � repr�senter une photographie.
Bien s�r, si la ressource originale est elle-m�me un fichier
ASCII, la repr�sentation ASCII sera consid�r� comme de meilleure
qualit� que la repr�sentation JPEG. La valeur de qs d�pend donc
de la nature de la ressource que l'on souhaite repr�senter.</p>
<p>La liste compl�te des en-t�tes utilisables est disponible
dans la documentation de
<a href="mod/mod_negotiation.html#typemaps">mod_negotation</a>.</p>
</section>
<section id="multiviews"><title>Multiviews</title>
<p>L'option <code>MultiViews</code> est � sp�cifier par r�pertoire,
ce qui signifie qu'elle peut �tre utilis�e au moyen d'une directive
<directive module="core">Options</directive> dans une section
<directive module="core" type="section">Directory</directive>,
<directive module="core" type="section">Location</directive> ou
<directive module="core" type="section">Files</directive>
du fichier <code>httpd.conf</code>, ou dans les fichiers
<code>.htaccess</code> (� condition que l'option <directive
module="core">AllowOverride</directive> soit param�tr�e pour cela).
Notez que <code>Options All</code> n'active pas l'option
<code>MultiViews</code>�; cette derni�re doit �tre positionn�e
explicitement.</p>
<p>Voici comment fonctionne <code>MultiViews</code>�: supposons qu'un
serveur re�oive une requ�te pour <code>/some/dir/foo</code>, que l'option
<code>MultiViews</code> soit activ�e pour <code>/some/dir</code>,
et que le fichier <code>/some/dir/foo</code> <em>n'</em>existe
<em>pas</em>�; alors le serveur cherche les fichiers nomm�s foo.*
dans le r�pertoire /some/dir, et construit une table de types �
partir de ces noms de fichiers. Dans la table, chaque fichier se
voit assigner les types de m�dias et les encodages de contenu
tels qu'ils seraient envoy�s si le client les demandait par leur
nom propre. Apache choisit alors la meilleure repr�sentation �
envoyer au client, en fonction de ses pr�f�rences.</p>
<p>L'option <code>MultiViews</code> sert aussi lors du choix d'un
index, lorsque la directive <directive
module="mod_dir">DirectoryIndex</directive> est pr�cis�e.
Par exemple, si la configuration contient</p>
<example>DirectoryIndex index</example>
<p>le serveur devra choisir entre les fichiers <code>index.html</code> et
<code>index.html3</code>, dans le cas o� ces deux fichiers existent. Si
aucun de ces fichiers n'existe, mais qu'un fichier <code>index.cgi</code>
est pr�sent, ce dernier sera ex�cut� par le serveur.</p>
<p>Si � la lecture du r�pertoire, un fichier est trouv�
dont l'extension n'est pas reconnue par <code>mod_mime</code>
comme pr�cisant son jeu de caract�res, sa langue, son type de
contenu (Content-Type) ou son encodage, alors tout d�pendra de la
directive <directive module="mod_mime">MultiViewsMatch</directive>.
Cette directive pr�cise en effet quels gestionnaires, filtres, et
autres types d'extensions peuvent contribuer � la n�gociation
MultiViews.</p>
</section>
</section>
<section id="methods"><title>M�thodes de N�gociations</title>
<p>Apr�s qu'Apache ait d�fini la liste de variantes possibles
pour une ressource, que ce soit via un fichier de tables de
types ou � partir des noms de fichiers contenus dans le r�pertoire,
deux m�thodes peuvent �tre invoqu�es pour choisir la 'meilleure'
variante qui sera envoy�e, pour autant qu'il en existe au moins
une. Il n'est pas n�cessaire de conna�tre ce fonctionnement pour
utiliser les n�gociations de contenu avec Apache�; cependant pour
le lecteur int�ress� la suite de ce document s'attache � d�crire
ce fonctionnement.</p>
<p>Il existe deux m�thodes de n�gociations�:</p>
<ol>
<li><strong>La n�gociation men�e par le serveur, selon
l'algorithme d'Apache</strong>, est utilis�e dans la plupart
des cas. L'algorithme d'Apache est d�taill� dans la suite de
ce document. Dans les cas o� cet algorithme est utilis�, il
arrive qu'Apache 'triche' sur le facteur qualit� (qs) d'une
dimension donn�e pour parvenir � un meilleur r�sultat. Les cas
o� cela se produit sont pr�sent�s dans la suite de ce document.</li>
<li><strong>La n�gociation transparente de contenu</strong>
est utilis�e sur demande sp�cifique du navigateur, selon la
m�thode d�finie dans la RFC 2295. Cette m�thode de n�gociation
donne au navigateur les pleins pouvoirs pour choisir la
'meilleure' variante, les r�sultats d�pendent donc des algorithmes
de choix propres � chaque navigateur. Cette m�thode permet
�galement au navigateur de demander � Apache d'utiliser
l'algorithme de 's�lection de variante � distance', tel que d�fini
par la RFC 2296.</li>
</ol>
<section id="dimensions"><title>Dimensions d'une N�gociation</title>
<table>
<columnspec><column width=".15"/><column width=".85"/></columnspec>
<tr valign="top">
<th>Dimension</th>
<th>Notes</th>
</tr>
<tr valign="top">
<td>Type de M�dia</td>
<td>Le navigateur pr�sente ses pr�f�rences au moyen du
champ <code>Accept</code> de l'en-t�te. � chaque �l�ment peut �tre
associ� un facteur de qualit�. De la m�me mani�re, la description
de la variante peut pr�senter un facteur de qualit� (le
param�tre "qs").</td>
</tr>
<tr valign="top">
<td>Langues</td>
<td>Le navigateur pr�sente ses pr�f�rences au moyen du champ
<code>Accept-Language</code> de l'en-t�te. � chaque �l�ment
peut �tre associ� un facteur de qualit�. Les diff�rentes
variantes peuvent �galement �tre associ�es ou non � une
ou plusieurs langues.</td>
</tr>
<tr valign="top">
<td>Encodage</td>
<td>Le navigateur pr�sente ses pr�f�rences au moyen du champ
<code>Accept-Encoding</code> de l'en-t�te. � chaque �l�ment
peut �tre associ� un facteur de qualit�.</td>
</tr>
<tr valign="top">
<td>Jeu de caract�res</td>
<td>Le navigateur pr�sente ses pr�f�rences au moyen du champ
<code>Accept-Charset</code> de l'en-t�te. � chaque �l�ment
peut �tre associ� un facteur de qualit�. Les diff�rentes
variantes peuvent se voir associer un jeu de caract�res
comme type de m�dia.</td>
</tr>
</table>
</section>
<section id="algorithm"><title>Algorithme de N�gociation d'Apache</title>
<p>Apache peut utiliser l'algorithme pr�sent� ci-apr�s pour choisir la
'meilleure' variante, si elle existe, � renvoyer au navigateur. Cet
algorithme n'est pas configurable. Il fonctionne de cette mani�re�:</p>
<ol>
<li>En premier lieu, pour chaque dimension de la n�gociation,
v�rifier le champ d'en-t�te <em>Accept*</em> appropri� et
attribuer un facteur de qualit� � chacune des variantes. Si
l'en-t�te <em>Accept*</em> d'une dimension indique que cette
variante n'est pas acceptable, �liminer cette variante. S'il
ne reste aucune variante, aller � l'�tape 4.</li>
<li>
Choisir la 'meilleure' des variantes par �limination.
Chacun des tests suivants est appliqu� dans cet ordre.
Toutes les variantes ne passant pas un test sont
syst�matiquement �limin�es. Apr�s chacun des tests, s'il
ne reste qu'une variante, la choisir comme la meilleure
et aller � l'�tape 3. S'il reste plus d'une variante, aller
� l'�tape suivante.
<ol>
<li>Multiplier le facteur de qualit� de l'en-t�te
<code>Accept</code> par le facteur qualit� de la source du
type de m�dia de cette variante, et choisir les variantes
avec le plus grand r�sultat.</li>
<li>Choisir les variantes qui pr�sentent le plus grand
facteur de qualit� de langue.</li>
<li>Choisir les variantes dont la langue correspond le
mieux, soit � l'ordre de pr�f�rence des langues dans
l'en-t�te <code>Accept-Language</code> (s'il existe),
soit � l'ordre des langues de la directive
<code>LanguagePriority</code> (si elle existe).</li>
<li>Choisir les variantes pr�sentant le param�tre de niveau
('level') de m�dia le plus grand (c'est ce qui est utilis�
pour conna�tre la version des types de m�dias text/html).</li>
<li>Choisir les variantes dont le jeu de caract�res est le
meilleur, par rapport � l'en-t�te <code>Accept-Charset</code>.
Le jeu de caract�res ISO-8859-1 est toujours acceptable, �
moins qu'il n'ait �t� explicitement refus�. Les variantes
avec un type de m�dia <code>test/*</code> et qui ne sont
pas explicitement associ�es � un jeu de caract�re donn�
sont suppos�es encod�es en ISO-8859-1.</li>
<li>Choisir les variantes qui ont un jeu de caract�res
d�fini et qui <em>n'</em>est <em>pas</em> ISO-8859-1.
S'il n'existe pas de telles variantes, alors les
choisir toutes.</li>
<li>Choisir les variantes pr�sentant le meilleur encodage.
S'il existe des variantes avec un encodage acceptable par
le 'user-agent' du navigateur, choisir ces variantes seules.
Dans le cas contraire, s'il existe � la fois des variantes
encod�es et non encod�es, ne choisir que les variantes
non encod�es. Dans les autres cas, choisir toutes les
variantes.</li>
<li>Choisir les variantes pr�sentant la plus petite taille.</li>
<li>Choisir la premi�re variante de celles qui restent. Ce
sera donc soit la premi�re variante list�e dans le fichier
des tables de types, soit, si les variantes sont lues d'un
r�pertoire, celle dont le nom appara�t en premier dans un
classement par code ASCII.</li>
</ol>
</li>
<li>Cet algorithme a permis de choisir la 'meilleure' des
variantes, qui est renvoy�e en r�ponse � la requ�te du
navigateur. L'en-t�te <code>Vary</code> de la r�ponse HTTP
est utilis� pour indiquer les dimensions de la n�gociation
(les navigateurs et les serveurs mandataires sont capables de
prendre en compte cette information quand il gardent une
ressource en cache). Fin des op�rations.</li>
<li>Arriver � ce point signifie qu'aucune variante n'a pu �tre
choisie, car aucune n'est acceptable aux yeux du navigateur.
Renvoyer une erreur 406 ("No acceptable representation" - NdT�:
"Aucune repr�sentation acceptable") dans un document HTML
pr�sentant les diverses variantes possibles. L'en-t�te HTTP
<code>Vary</code> est �galement renseign� pour pr�senter les
dimensions de la n�gociation.</li>
</ol>
</section>
</section>
<section id="better"><title>Tricher sur les Facteurs de Qualit�</title>
<p>Il arrive qu'Apache modifie les facteurs de qualit� par rapport
� la valeur qu'ils devraient avoir en suivant strictement
l'algorithme d�crit plus haut. Ceci permet d'obtenir de meilleurs
r�sultats pour g�rer les navigateurs qui n'envoient pas toutes
les informations ou envoient des informations erron�es. Ainsi,
certains navigateurs, parmi les plus r�pandus du march�, envoient
des en-t�tes <code>Accept</code> qui entra�neraient l'envoi de la
mauvaise variante dans de nombreux cas. Si le navigateur envoie
des informations correctes, Apache ne trichera pas sur les facteurs
de qualit�.</p>
<section id="wildcards"><title>Types de M�dias et Jokers</title>
<p>L'en-t�te de requ�te <code>Accept:</code> indique les pr�f�rences
des types de m�dias. Elle peut comporter des 'jokers' tels que
"image/*" ou "*/*", o� * signifie "n'importe quoi". Ainsi, une
requ�te pr�sentant�:</p>
<example>Accept: image/*, */*</example>
<p>signifierait que tout type commen�ant par "image/" est
acceptable, comme serait acceptable tout autre type. Certains
navigateurs envoient sans arr�t des jokers en plus des types
qu'ils peuvent effectivement g�rer. Par exemple�:</p>
<example>
Accept: text/html, text/plain, image/gif, image/jpeg, */*
</example>
<p>Le but de ces informations est d'indiquer que les types
explicitement cit�s sont les pr�f�r�s mais que le
navigateur accepte �galement d'autres repr�sentations.
En utilisant les facteurs de qualit�, voici ce que devrait
envoyer le navigateur�:</p>
<example>
Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01
</example>
<p>Les types explicitement cit�s ne pr�sentent pas de facteur
de qualit�, ils re�oivent donc la valeur par d�faut de 1.0
(la plus haute valeur possible). Les jokers sont affect�s
d'une pr�f�rence tr�s basse de 0.01, si bien que les autres
types ne seront utilis�s que si aucune des variantes ne
correspond � un des types explicitement pr�f�r�s.</p>
<p>Si le champ d'en-t�te <code>Accept:</code> <em>ne</em>
contient <em>aucun</em> facteur de qualit�, Apache modifie
le facteur de qualit� de "*/*" (s'il est pr�sent) en 0.01
afin d'�muler le comportement souhait�. Apache positionne
�galement le facteur de qualit� des jokers qui se pr�sentent
sous la forme "type/*" en 0.02 (afin que ces derniers soient
pr�f�r�s � "*/*"). Si un seul ou plusieurs types de m�dia de
l'en-t�te <code>Accept:</code> pr�sente un facteur de qualit�,
ces modifications <em>ne</em> sont <em>pas</em> effectu�es,
afin que les requ�tes des navigateurs qui envoient des
informations correctes fonctionnent comme pr�vu.</p>
</section>
<section id="exceptions"><title>Exceptions aux N�gociations sur la Langue</title>
<p>� partir d'Apache 2.0, certaines exceptions ont �t� ajout�es
� l'algorithme de n�gociation afin de retomber �l�gamment sur
nos pattes dans les cas o� la n�gociation sur la langue
n'aboutit pas.</p>
<p>Si un client demande une page du serveur, sans que ce dernier
ne puisse d�terminer une page correspondant au champ
<code>Accept-language</code> envoy� par le navigateur, le serveur
doit renvoyer une r�ponse parmi "Pas de Variante Acceptable"
et "Choix Multiples" au client. Afin d'�viter ces messages
d'erreur, il est possible de configurer Apache pour qu'il ignore
le champ <code>Accept-language</code> dans ces cas et qu'il
fournisse au client un document qui ne correspond pas
explicitement � sa requ�te. La directive
<directive module="mod_negotiation">ForceLanguagePriority</directive>
peut �tre utilis�e pour passer outre � ces deux messages d'erreur
et modifier la r�ponse du serveur au moyen de la directive
<directive module="mod_negotiation">LanguagePriority</directive>.</p>
<p>Le serveur va �galement essayer de modifier la sous-classe
de langue si aucune correspondance n'est trouv�e. Par exemple,
dans le cas o� un client demande des documents avec le langage
<code>en-GB</code> pour "British English", le protocole HTTP/1.1
n'autorise pas le serveur � r�pondre par un document qui serait
marqu� par <code>en</code>. (Notez que pr�senter
<code>en-GB</code> dans l'en-t�te <code>Accept-language</code>
est loin d'�tre pertinent, il semble tr�s peu probable que le
lecteur comprenne l'anglais "British" et ne comprenne pas
l'anglais "tout court". Il se trouve malheureusement que
beaucoup de navigateurs pr�sentent ce comportement.) Bref,
si aucune autre langue ne correspond et que le serveur
s'appr�terait normalement � envoyer une r�ponse d'erreur
"No Acceptable Variants", ou � utiliser la m�thode
<directive module="mod_negociation">LanguagePriority</directive>
pr�sent�e ci-avant, le serveur va ignorer la sous-classe de
langue <code>GB</code> et consid�rer que la requ�te
<code>en-GB</code> correspond bien au document <code>en</code>.
Implicitement, Apache ajoute la langue parente (<code>en</code>)
� la liste des langues consid�r�es comme acceptables par le
navigateur, avec un facteur de qualit� tr�s faible. Notez
cependant que si le client demande "en-GB; qs=0.9, fr; qs=0.8",
et que le serveur dispose de documents marqu�s comme "en" et
"fr", alors le document en fran�ais sera renvoy� par le serveur.
Ce comportement est n�cessaire, afin de garder la compatibilit�
avec HTTP/1.1 et fonctionner avec les navigateurs correctement
configur�s.</p>
<p>Pour supporter les techniques avanc�es de d�tection de
pr�f�rence de langues de l'utilisateur (telles que les
Cookies, ou les chemins d'URL sp�ciaux), Apache reconna�t
depuis la version 2.0.47 la <a href="env.html">variable
d'environnement</a> <code>prefer-language</code>. Si cette
variable existe, et qu'elle pr�cise une langue valide,
<module>mod_negociation</module> cherchera une variante qui
y corresponde. S'il n'en trouve pas, le processus de
n�gociation normal se d�roulera.</p>
<example><title>Exemple</title>
SetEnvIf Cookie "language=en" prefer-language=en<br />
SetEnvIf Cookie "language=fr" prefer-language=fr
</example>
</section>
</section>
<section id="extensions"><title>Extensions vers la N�gociation de Contenu
Transparente</title>
<p>Apache compl�te le protocole de n�gociation de contenu (RFC 2295)
comme d�crit ici. Un nouvel �l�ment <code>{encoding ..}</code> est
utilis� dans la liste des variantes pour nommer celles qui ne sont
disponibles que sous un encodage sp�cifique. L'impl�mentation de
l'algorithme RVSA/1.0 (RFC 2296) est �tendue afin d'int�grer les
variantes encod�es dans la liste, et de les proposer comme
candidates quand leur encodage est acceptable au vu de l'en-t�te
<code>Accept-Encoding</code>. L'impl�mentation RVSA/1.0 ne tronque
pas les facteurs de qualit� � 5 d�cimales avant de choisir la
meilleure des variantes.</p>
</section>
<section id="naming"><title>� propos des liens hypertextes et des conventions de nommage</title>
<p>Dans le cas o� la n�gociation de langues est utilis�e, il est
possible de choisir diverses conventions de nommage, car les
fichiers peuvent pr�senter plus d'une extension, et l'ordre des
extensions n'est normalement pas significatif (voir la
documentation <a href="mod/mod_mime.html#multipleext">mod_mime</a>
pour plus de d�tails).</p>
<p>Habituellement, un fichier a une extension pour son type MIME
(par exemple, <code>html</code>), parfois une extension pour son
encodage (par exemple, <code>gz</code>), et bien s�r une extension
de langue (par exemple, <code>en</code>) pour distinguer les
diverses variantes.</p>
<p>Exemples�:</p>
<ul>
<li>foo.en.html</li>
<li>foo.html.en</li>
<li>foo.en.html.gz</li>
</ul>
<p>Voici d'autres exemples de noms de fichiers ainsi que des liens
hypertextes valides et invalides�:</p>
<table border="1" cellpadding="8" cellspacing="0">
<columnspec><column width=".2"/><column width=".2"/>
<column width=".2"/></columnspec>
<tr>
<th>Nom de Fichier</th>
<th>Lien valide</th>
<th>Lien invalide</th>
</tr>
<tr>
<td><em>foo.html.en</em></td>
<td>foo<br />
foo.html</td>
<td>-</td>
</tr>
<tr>
<td><em>foo.en.html</em></td>
<td>foo</td>
<td>foo.html</td>
</tr>
<tr>
<td><em>foo.html.en.gz</em></td>
<td>foo<br />
foo.html</td>
<td>foo.gz<br />
foo.html.gz</td>
</tr>
<tr>
<td><em>foo.en.html.gz</em></td>
<td>foo</td>
<td>foo.html<br />
foo.html.gz<br />
foo.gz</td>
</tr>
<tr>
<td><em>foo.gz.html.en</em></td>
<td>foo<br />
foo.gz<br />
foo.gz.html</td>
<td>foo.html</td>
</tr>
<tr>
<td><em>foo.html.gz.en</em></td>
<td>foo<br />
foo.html<br />
foo.html.gz</td>
<td>foo.gz</td>
</tr>
</table>
<p>Le tableau ci-dessus montre qu'il est toujours possible de
sp�cifier le lien sans aucune extension dans un lien hypertexte.
(par exemple, <code>foo</code>). L'avantage en est qu'il est
ainsi possible de ne pas montrer le type d'un document, et de
le modifier ult�rieurement, par exemple le passer de <code>html</code>
� <code>shtml</code> ou <code>cgi</code> sans avoir besoin de
modifier aucun lien.</p>
<p>Pour continuer � utiliser les types MIME dans les liens
(par exemple, <code>foo.html</code>), l'extension correspondant
� la langue (ainsi que l'extension d'encodage, si elle existe)
doit �tre du cot� droit de l'extension du type MIME (par exemple,
<code>foo.html.en</code>).</p>
</section>
<section id="caching"><title>� propos des Caches</title>
<p>Quand un cache garde en m�moire une repr�sentation, il l'associe
� l'URL de la requ�te. Quand la m�me URL vient � �tre redemand�e,
le cache peut utiliser la repr�sentation gard�e en m�moire, plut�t
que de refaire une requ�te au serveur. Cependant, si la ressource
est n�gociable cot� serveur, le r�sultat pourrait en �tre que la
r�ponse � la premi�re requ�te mise en cache serait renvoy�e de
fa�on erron�e. Pour pr�venir ce probl�me, Apache marque toutes
les r�ponses issues d'une n�gociation comme "non-cachables" par
les clients HTTP/1.0. Apache supporte les sp�cifications du
protocole HTTP/1.1 en ce qui concerne la mise en cache des
r�ponses n�goci�es.</p>
<p>Les requ�tes venant d'un client conforme au protocole HTTP/1.0
(qu'il s'agisse d'un navigateur ou d'un serveur cache) peuvent
�tre rendues "cachables" si la directive <directive
module="mod_negociation">CacheNegotiatedDocs</directive> est
utilis�e. Cette directive peut �tre sp�cifi�e aussi bien dans
la configuration principale du serveur que dans un serveur
virtuel, et ne n�cessite pas d'argument. Elle n'a aucun impact
sur les requ�tes des clients fonctionnant en HTTP/1.1.</p>
</section>
<section id="more"><title>Plus d'Information</title>
<p>Pour plus d'informations au sujet de la n�gociation de contenu, voir
<a href="http://ppewww.ph.gla.ac.uk/~flavell/www/lang-neg.html";>Language
Negotiation Notes</a> de Alan J. Flavell. Notez que ce
document ne sera peut-�tre pas mis � jour en fonction des
changements intervenus dans Apache 2.0.</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 2002-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="configuring.xml.meta">
<title>Fichiers de Configuration</title>
<summary>
<p>Ce document pr�sente les fichiers utilis�s pour la configuration
du serveur HTTP Apache.</p>
</summary>
<section id="main">
<title>Fichiers de Configuration principaux</title>
<related>
<modulelist>
<module>mod_mime</module>
</modulelist>
<directivelist>
<directive module="core" type="section">IfDefine</directive>
<directive module="core">Include</directive>
<directive module="mod_mime">TypesConfig</directive>
</directivelist>
</related>
<p>Apache se configure en positionnant des <a
href="mod/directives.html">directives</a> dans des fichiers de
configurations, au format texte. Le fichier de configuration principal
est habituellement nomm� <code>httpd.conf</code>.
L'emplacement de ce fichier est d�fini lors de la compilation
mais il est possible de le modifier en ligne de commande au lancement
d'Apache au moyen de l'option <code>-f</code>.
De plus, il est possible d'ajouter d'autres fichiers de configuration au
moyen de la directive <directive module="core">Include</directive>,
qui accepte des jokers, rendant possible la lecture de multiples
fichiers de configuration. Cette directive peut �tre incluse dans
n'importe quel fichier de configuration. Les changements apport�s
aux fichiers de configuration principale ne seront pris en compte
qu'au d�marrage d'Apache ou � son red�marrage.</p>
<p>Le serveur lit �galement un fichier contenant les types de documents
mime�; le nom de ce fichier est d�fini au moyen de la directive
<directive module="mod_mime">TypesConfig</directive>, et son nom
par d�faut est <code>mime.types</code>.</p>
</section>
<section id="syntax">
<title>Syntaxe des fichiers de configuration</title>
<p>Les fichiers de configuration d'Apache contiennent une directive par
ligne. Il est possible d'utiliser le caract�re antislash "\" � la fin
d'une ligne pour signaler que celle-ci se continue sur la ligne suivante.
Dans ce cas l'antislash doit imp�rativement �tre le tout dernier
caract�re de la ligne et ne doit pas �tre suivi d'espaces.</p>
<p>Les directives plac�es dans les fichiers de configuration
ne sont pas sensibles � la casse, mais leurs arguments le sont.
Les lignes commen�ant par le caract�re "#" sont consid�r�es comme
des commentaires, et sont donc ignor�es. Il <strong>n'</strong>est
<strong>pas</strong> possible d'ajouter un commentaire en fin de
ligne, apr�s une directive. Les lignes vides, ainsi que les
espaces pr�c�dant les directives, sont ignor�s, ce qui vous
permet d'indenter le fichier pour de simplifier sa lecture.</p>
<p>Vous pouvez tester vos fichiers de configuration sans
avoir � d�marrer le serveur en utilisant la commande
<code>apachectl configtest</code> ou en appelant Apache
avec l'option <code>-t</code>.</p>
</section>
<section id="modules">
<title>Modules</title>
<related>
<modulelist>
<module>mod_so</module>
</modulelist>
<directivelist>
<directive module="core" type="section">IfModule</directive>
<directive module="mod_so">LoadModule</directive>
</directivelist>
</related>
<p>Apache est un serveur modulaire, ce qui signifie que le
noyau du serveur ne dispose que des fonctions des plus basiques.
Toutes les fonctions �tendues sont possibles gr�ce � des <a
href="mod/">modules</a>, qui peuvent �tre charg�s par Apache.
Par d�faut, un <a href="mod/module-dict.html#Status">certain
nombre</a> de modules est fourni et compil� avec le serveur.
Dans le cas o� le serveur a �t� compil� avec le <a href="dso.html">
support dynamique des modules</a>, il est possible de compiler
des modules � part et de les charger au moyen de la directive
<directive module="mod_so">LoadModule</directive>. Dans le cas
contraire, il faudra recompiler tout Apache pour lui ajouter ou
lui enlever des modules. Des directives peuvent �tre incluses de
fa�on conditionnelle selon la pr�sence d'un module particulier en
les positionnant dans un bloc <directive module="core"
type="section">IfModule</directive>.</p>
<p>L'option <code>-l</code>, � passer en ligne de commande, provoque
l'affichage des modules qui sont compil�s dans Apache.</p>
</section>
<section id="scope">
<title>Directives Possibles</title>
<related>
<directivelist>
<directive module="core" type="section">Directory</directive>
<directive module="core" type="section">DirectoryMatch</directive>
<directive module="core" type="section">Files</directive>
<directive module="core" type="section">FilesMatch</directive>
<directive module="core" type="section">Location</directive>
<directive module="core" type="section">LocationMatch</directive>
<directive module="core" type="section">VirtualHost</directive>
</directivelist>
</related>
<p>Les directives positionn�es dans les fichiers de configuration principaux
s'appliquent au serveur dans son ensemble. Pour sp�cifier des directives
sp�cifiques � une partie du serveur, il est possible de les positionner �
l'int�rieur d'une des sections <directive module="core"
type="section">Directory</directive>, <directive module="core"
type="section">DirectoryMatch</directive>, <directive module="core"
type="section">Files</directive>, <directive module="core"
type="section">FilesMatch</directive>, <directive module="core"
type="section">Location</directive>, ou <directive module="core"
type="section">LocationMatch</directive>.
Chacune de ces sections limite la validit� des directives qu'elle
contient � la partie du syst�me de fichier ou de l'URL qu'elle
contient. Ces sections peuvent �galement se contenir les unes les autres,
ce qui permet une configuration tr�s fine.</p>
<p>Il est possible d'utiliser un seul serveur Apache pour servir plusieurs
sites web, ce qu'on appelle des <a href="vhosts/">Serveurs Virtuels</a>.
Les diff�rentes directives peuvent �tre positionn�es � l'int�rieur de
sections <directive module="core" type="section">VirtualHost</directive>,
afin qu'elles r�gulent le fonctionnement d'un site (dit virtuel)
particulier.</p>
<p>La plupart des directives peuvent �tre positionn�es dans toutes les
sections pr�sent�es ci-dessus, sauf dans certains cas. Par exemple,
les directives qui contr�lent la cr�ation du processus Apache ne
peuvent �tre plac�es que dans le contexte du serveur principal. Les
sections possibles pour chaque directive sont d�crites au niveau du <a
href="mod/directive-dict.html#Context">Contexte</a> de celle-ci.
Des informations plus compl�tes au sujet du fonctionnement des sections
<a href="sections.html">Directory, Location et Files</a>
sont disponibles ailleurs.</p>
</section>
<section id="htaccess">
<title>Fichiers .htaccess</title>
<related>
<directivelist>
<directive module="core">AccessFileName</directive>
<directive module="core">AllowOverride</directive>
</directivelist>
</related>
<p>Apache permet de d�localiser la gestion de la configuration, au
moyen de fichiers sp�ciaux, plac�s directement dans l'arborescence Web.
Ces fichiers sp�ciaux portent le plus souvent le nom <code>.htaccess</code>,
mais il est bien s�r possible de changer ce nom au moyen de la directive
<directive module="core">AccessFileName</directive>.
Les directives positionn�es dans un fichier <code>.htaccess</code>
s'appliquent au r�pertoire le contenant ainsi qu'� tous ses
sous-r�pertoires. La syntaxe � employer dans un fichier
<code>.htaccess</code> est identique � la syntaxe des fichiers de
configuration principaux. De plus, les fichiers <code>.htaccess</code>
�tant lus au moment de chaque requ�te les concernant, toute
modification de ces fichiers prend effet imm�diatement sans qu'il soit
n�cessaire de red�marrer le serveur.</p>
<p>Pour savoir si une directive peut �tre plac�e dans un fichier
<code>.htaccess</code>, il suffit de v�rifier son <a
href="mod/directive-dict.html#Context">Contexte</a>. Il est possible �
l'administrateur du serveur de sp�cifier quelles directives sont
autoris�es ou non dans les fichiers <code>.htaccess</code>, au moyen
de la directive <directive module="core">AllowOverride</directive>,
positionn�e dans les fichiers de configuration principaux.</p>
<p>Des informations plus compl�tes concernant les fichiers
<code>.htaccess</code> sont disponible dans le
<a href="howto/htaccess.html">tutoriel .htaccess</a>.</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 2002-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="bind.xml.meta">
<title>Liaison</title>
<summary>
<p>Configuration des adresses et ports sur lesquels Apache �coute.</p>
</summary>
<seealso><a href="vhosts/">Serveurs Virtuels</a></seealso>
<seealso><a href="dns-caveats.html">Probl�mes DNS</a></seealso>
<section id="overview">
<title>Informations g�n�rales</title>
<related>
<modulelist>
<module>core</module>
<module>mpm_common</module>
</modulelist>
<directivelist>
<directive module="core" type="section">VirtualHost</directive>
<directive module="mpm_common">Listen</directive>
</directivelist>
</related>
<p>Au moment de son d�marrage, Apache se lie � un port et � une
adresse sur la machine et se met en attente de requ�tes entrantes.
Par d�faut, toutes les adresses de la machine se retrouvent
� l'�coute. Dans tous les cas, Apache accepte d'�couter sur un
ou plusieurs ports sp�cifiques, ou sur une seule ou plusieurs
adresses, ou encore une combinaison des deux.
Il est fr�quent d'utiliser ces possibilit�s avec les fonctionnalit�s
de Serveurs Virtuels, qui permettent de faire r�pondre Apache de
mani�re diff�rente en fonction de l'adresse IP, du nom ou du port.</p>
<p>Le serveur utilise la directive
<directive module="mpm_common">Listen</directive>
pour n'accepter que des requ�tes provenant de ports sp�cifiques ou
d'une combinaison adresse IP + port pass�s en argument.
Dans le cas o� seul un port est sp�cifi� avec la directive
<directive module="mpm_common">Listen</directive>,
le serveur se met � l'�coute sur le port sp�cifi�, sur toutes
les interfaces et adresses de la machine. Si une adresse IP est
pr�cis�e en plus du port, le serveur n'�coute que sur l'adresse
et le port sp�cifi�s. Il est possible de configurer plusieurs
directives <directive module="mpm_common">Listen</directive>,
afin qu'Apache �coute sur plusieurs adresses
et ports. Dans ce cas, le serveur r�pondra aux requ�tes faites
sur tous les adresses et ports �num�r�s.</p>
<p>Par exemple, pour que le serveur accepte les connexions � la fois sur
les ports 80 et 8000, sp�cifiez�:</p>
<example>
Listen 80<br />
Listen 8000
</example>
<p>Pour qu'Apache accepte les connexions sur deux combinaisons
adresses + ports, sp�cifiez�:</p>
<example>
Listen 192.170.2.1:80<br />
Listen 192.170.2.5:8000
</example>
<p>Les adresses IPv6 sont accept�es, pourvu qu'elles soient entour�es
entre crochets de la fa�on suivante�:</p>
<example>
Listen [fe80::a00:20ff:fea7:ccea]:80
</example>
</section>
<section id="ipv6">
<title>Pr�cisions au sujet d'IPv6</title>
<p>De plus en plus de plates-formes impl�mentent IPv6, et APR
supporte IPv6 sur la plupart d'entre elles, si bien qu'Apache
peut utiliser des sockets IPv6 et r�pondre aux requ�tes envoy�es
en IPv6.</p>
<p>Une complication possible pour les administrateurs Apache est de
savoir si un socket IPv6 est capable de g�rer les connexions IPv4
aussi bien qu'IPv6. G�rer les connexions IPv4 sur une socket IPv6
suppose l'utilisation d'adresses IPv6 mapp�es en IPv4, ce qui est
le cas sur la plupart des plates-formes, mais pas sur FreeBSD, NetBSD
et OpenBSD, en raison des politiques syst�mes de ces plates-formes.
M�me sur des syst�mes o� cette fonctionnalit� n'est pas activ�e par
d�faut, un param�tre de compilation pour <program>configure</program>
permet de changer ce comportement pour Apache.</p>
<p>Pour qu'Apache puisse g�rer � la fois les connexions IPv4 et IPv6
avec un minimum de sockets, il faut permettre l'utilisation des adresses
IPv6 mapp�es en IPv4, ce qui est faisable en sp�cifiant l'option
de compilation <code>--enable-v4-mapped</code> et en utilisant la
directive g�n�rique <directive module="mpm_common">Listen</directive>
comme suit�:</p>
<example>
Listen 80
</example>
<p>Si <code>--enable-v4-mapped</code> a �t� sp�cifi� � la compilation,
les directives Listen de la configuration par d�faut sont de la forme
ci-dessus. <code>--enable-v4-mapped</code> est l'option de compilation
par d�faut sur toutes les plates-formes, sauf pour FreeBSD, NetBSD, et
OpenBSD, donc il est probable que votre Apache ait �t� compil� avec
cette option.</p>
<p>Pour qu'Apache ne g�re que les connexions IPv4, en ignorant l'�ventuel
support IPv6 de la plate-forme ou d'APR, une adresse IPv4 peut �tre
donn�e dans toutes les directives
<directive module="mpm_common">Listen</directive>, comme dans les
exemples suivants�:</p>
<example>
Listen 0.0.0.0:80<br />
Listen 192.170.2.1:80
</example>
<p>Pour qu'Apache g�re les connexions IPv4 et IPv6 sur des sockets
diff�rents (i.e., pour ne pas accepter les adresses IPv6 mapp�es
en IPv4), sp�cifiez l'option de compilation
<code>--disable-v4-mapped</code> et utilisez des directives
Listen sp�cifiques telles que�:</p>
<example>
Listen [::]:80<br />
Listen 0.0.0.0:80
</example>
<p>Si le param�tre <code>--disable-v4-mapped</code> a �t� d�fini
au moment de la compilation, les directives Listen de la
configuration par d�faut sont de la forme ci-dessus.
<code>--disable-v4-mapped</code> est l'option de
compilation par d�faut sous FreeBSD, NetBSD, et OpenBSD.</p>
</section>
<section id="virtualhost">
<title>Faire fonctionner tout ceci avec les Serveurs Virtuels</title>
<p>La directive <directive module="mpm_common">Listen</directive>
n'impl�mente aucun Serveur Virtuel. Elle sert simplement �
indiquer au serveur principal sur quels adresses et ports �couter.
Dans le cas o� aucune section
<directive module="core" type="section">VirtualHost</directive>
n'est utilis�e, le serveur r�pondra de la m�me mani�re pour toutes
les requ�tes qu'il recevra.
Des sections
<directive module="core" type="section">VirtualHost</directive>
peuvent �tre utilis�es pour qu'Apache r�agisse diff�remment selon que la
requ�te est destin�e � telle adresse ou � tel port. Avant d'impl�menter
un Serveur Virtuel au moyen de la directive VirtualHost, la directive
Listen doit �tre configur�e pour que le serveur �coute sur l'adresse
ou le port utilis�. Ensuite, une section
<directive module="core" type="section">VirtualHost</directive>
devrait �tre utilis�e pour qu'Apache r�agisse diff�remment selon
l'adresse ou le port.
� noter que si un Serveur Virtuel
<directive module="core" type="section">VirtualHost</directive>
est configur� sur une adresse et un port sur lesquels le serveur
n'est pas � l'�coute, le Serveur Virtuel ne sera pas accessible.</p>
</section>
</manualpage>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
