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]
