details.xml.fr revision eec3a6d65a733157dc4cf3026abda13dcb90d0cf
<?xml version='1.0' encoding='ISO-8859-1' ?>
<!-- English Revision: 151405:151408 (outdated) -->
<!-- French translation by Vincent Deffontaines, review by alain B -->
<!--
Copyright 2005 The Apache Software Foundation or its licensors, as
applicable.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
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="details.xml.meta">
<parentdocument href="./">Serveurs virtuels</parentdocument>
<title>D�tails sur le fonctionnement des serveurs virtuels</title>
<summary>
<p>Le code g�rant les serveurs virtuels a �t� r��crit � partir de
z�ro dans <strong>Apache 1.3</strong>. Ce document vise � expliquer
dans le d�tail comment Apache proc�de lors du choix de l'utilisation
d'un serveur virtuel en fonction d'une requ�te re�ue. L'apparition
de la directive <directive module="core">NameVirtualHost</directive>
a rendu beaucoup plus facile et plus s�re la configuration des
serveurs virtuels par rapport aux versions pr�c�dant la 1.3.</p>
<p>Si vous voulez juste <cite>que �a marche</cite> sans en
comprendre le fonctionnement, voici <a href="examples.html">quelques
exemples</a>.</p>
</summary>
<section id="configparsing"><title>Interpr�tation des fichiers
de configuration</title>
<p>Un <em>serveur principal (main_server)</em> contient toutes
les d�finitions qui apparaissent en dehors des sections
<code><VirtualHost></code>. Les serveurs virtuels, aussi
appel�s <em>vhosts</em> (pour virtual hosts), sont d�finis par les
sections <directive type="section" module="core">VirtualHost</directive>.</p>
<p>Les directives
<directive module="mpm_common">Listen</directive>,
<directive module="core">ServerName</directive>,
<directive module="core">ServerPath</directive>,
et <directive module="core">ServerAlias</directive>
peuvent �tre plac�es n'importe o� dans le cadre de d�finition d'un
serveur. Cependant, chaque fois que l'une d'elles est lue, elle �crase
ses instances pr�c�dentes (dans le contexte du m�me serveur).</p>
<p>La valeur par d�faut du champ <code>Listen</code> pour le serveur
principal est de 80. Le serveur principal n'a pas de valeur par
d�faut pour <code>ServerPath</code> ni pour <code>ServerAlias</code>.
La valeur par d�faut de <code>ServerName</code> est d�duite � partir
de l'adresses IP du serveur.</p>
<p>La directive Listen associ�e au serveur principal a deux utilit�s.
La premi�re d�termine le port r�seau sur lequel Apache va �couter.
La deuxi�me sp�cifie le port qui sera utilis� dans les URIs absolus
lors des redirections.</p>
<p>� la diff�rence du serveur principal, les ports des serveurs
virtuels <em>n</em>'affectent <em>pas</em> les ports sur lesquels
Apache se met � l'�coute.</p>
<p>Chaque adresse incluse dans une directive <code>VirtualHost</code>
peut disposer d'un port optionnel. Si le port n'est pas pr�cis�, il
prend par d�faut la derni�re valeur de <code>Listen</code> lue dans
la configuration du serveur principal. Le port particulier
<code>*</code> repr�sente un joker qui correspond � tous les ports.
L'ensemble des adresses (y compris les r�sultats multiples
<code>A</code> issus des requ�tes DNS) est appel� <em>jeu
d'adresses</em> du serveur virtuel.</p>
<p>� moins qu'une directive
<directive module="core">NameVirtualHost</directive> ne soit utilis�e
pour une adresse IP sp�cifique, le premier serveur virtuel avec
cette adresse est consid�r� comme un <em>serveur virtuel par-IP</em>.
L'adresse IP peut �galement prendre la valeur joker <code>*</code>.</p>
<p>Dans les cas o� l'on souhaite utiliser un <em>serveur virtuel
par nom</em>, la directive <code>NameVirtualHost</code> <em>doit</em>
appara�tre avec l'adresse IP choisie. En d'autres termes, vous devez
sp�cifier dans votre fichier de configuration l'adresse IP des noms
de domaine (CNAME) de vos serveurs virtuels par nom au moyen de
la directive <code>NameVirtualHost</code>.</p>
<p>On peut utiliser plusieurs directives <code>NameVirtualHost</code>
pour un groupe de directives <code>VirtualHost</code>, mais seule
une directive <code>NameVirtualHost</code> doit �tre utilis�e pour
chaque couple IP:port donn�.</p>
<p>L'ordre d'apparition des directives <code>NameVirtualHost</code>
et <code>VirtualHost</code> est sans importance, ce qui fait que
les deux exemples suivants ont des effets identiques (seul l'ordre
des directives <code>VirtualHost</code> pour <em>un</em> jeu
d'adresses est important, voir ci-dessous) :</p>
<table><tr>
<td><example>
NameVirtualHost 111.22.33.44<br />
<VirtualHost 111.22.33.44><br />
# serveur A<br />
...<br />
</VirtualHost><br />
<VirtualHost 111.22.33.44><br />
# serveur B<br />
...<br />
</VirtualHost><br />
<br />
NameVirtualHost 111.22.33.55<br />
<VirtualHost 111.22.33.55><br />
# serveur C<br />
...<br />
</VirtualHost><br />
<VirtualHost 111.22.33.55><br />
# serveur D<br />
...<br />
</VirtualHost>
</example></td>
<td><example>
<VirtualHost 111.22.33.44><br />
# serveur A<br />
</VirtualHost><br />
<VirtualHost 111.22.33.55><br />
# serveur C<br />
...<br />
</VirtualHost><br />
<VirtualHost 111.22.33.44><br />
# serveur B<br />
...<br />
</VirtualHost><br />
<VirtualHost 111.22.33.55><br />
# serveur D<br />
...<br />
</VirtualHost><br />
<br />
NameVirtualHost 111.22.33.44<br />
NameVirtualHost 111.22.33.55<br />
<br />
</example></td>
</tr></table>
<p>(Il est conseill� d'adopter le choix de gauche pour faciliter
la lisibilit� des fichiers de configuration.)</p>
<p>Apr�s la lecture de la directive <code>VirtualHost</code>, le
serveur virtuel se voit attribuer une valeur <code>Listen</code>
par d�faut qui est la valeur du port associ� au premier nom sp�cifi�
dans sa directive <code>VirtualHost</code>.</p>
<p>La liste compl�te des noms d'une directive <code>VirtualHost</code>
est g�r�e exactement comme des <code>ServerAlias</code> (mais ne
sont pas �cras�s par d'autres <code>ServerAlias</code>) si tous
les noms sont r�solus dans ce jeu d'adresse. � noter que les �tats
<code>Listen</code> de ce serveur virtuel sont sans incidence sur
les ports attibu�s au jeu d'adresses.</p>
<p>Pendant la phase d'initialisation, une liste de chaque adresse
IP est g�n�r�e et introduite dans une table de 'hash'. Si une
adresse IP est utilis�e dans une directive <code>NameVirtualHost</code>,
cette liste contient les noms des serveurs virtuels pour cette
adresse. Si aucun serveur virtuel n'est d�fini pour cette adresse,
la directive <code>NameVirtualHost</code> est ignor�e et un message
est envoy� au journal d'erreurs. Quand un serveur virtuel par IP
est utilis�, la table de 'hash' reste vide.</p>
<p>La fonction de 'hash' �tant rapide, le temps d'ex�cution d'un
'hash' sur une adresse IP lors d'une requ�te est minimale et
quasiment imperceptible. De plus, la table est optimis�e pour les
adresses IP dont le dernier octet est le seul � changer.</p>
<p>Pour chaque serveur virtuel, diverses valeurs sont initialis�es
par d�faut. En particulier :</p>
<ol>
<li>Dans le cas o� un serveur virtuel ne contient pas de directives
<directive module="core">ServerAdmin</directive>,
<directive module="core">ResourceConfig</directive>,
<directive module="core">AccessConfig</directive>,
<directive module="core">Timeout</directive>,
<directive module="core">KeepAliveTimeout</directive>,
<directive module="core">KeepAlive</directive>,
<directive module="core">MaxKeepAliveRequests</directive>,
ou <directive module="core">SendBufferSize</directive>,
alors la valeur de chacun de ces param�tres est h�rit�e de celle du
serveur principal. (C'est � dire, h�rit�e de la valeur finale apr�s
lecture de la configuration du serveur principal.)</li>
<li>Les permissions par d�faut sur les r�pertoires de chaque
serveur virtuel sont assembl�es avec celles du serveur principal.
Elles concernent �galement toutes les informations de configuration
par r�pertoire pour tous les modules.</li>
<li>Les configurations par serveur pour chaque module sont assembl�es
� partir de celles du serveur principal.</li>
</ol>
<p>L'essentiel des valeurs de configuration des serveurs virtuels
provient de valeurs par d�faut issues du serveur principal.
Mais la position dans le fichier de configuration des directives
du serveur principal n'a pas d'importance -- l'ensemble de la
configuration du serveur principal est lu avant que ces valeurs par
d�faut soient appliqu�es aux serveur virtuels. Ainsi, m�me si la
d�finition d'une valeur appara�t apr�s celle d'un serveur virtuel,
cette valeur peut affecter la definition du serveur virtuel.</p>
<p>Dans le cas o� le serveur principal n'a pas de <code>ServerName</code>
� ce stade, le nom de la machine sur laquelle tourne le programme
<program>httpd</program> est utilis� � sa place. Nous appellerons
<em>jeu d'adresses du serveur principal</em>, les adresses IP
renvoy�es par une r�solution DNS sur le <code>ServerName</code>
du serveur principal.</p>
<p>Pour tous les champs <code>ServerName</code> non d�finis, dans
le cas d'une configuration en serveur virtuel par nom, la valeur
adopt�e par d�faut est la premi�re adresse donn�e dans la section
<code>VirtualHost</code> qui d�finit le serveur virtuel.</p>
<p>Si un serveur virtuel contient la valeur magique
<code>_default_</code>, il fonctionne sur le m�me <code>ServerName</code>
que le serveur principal.</p>
</section>
<section id="hostmatching"><title>Choix du serveur virtuel</title>
<p>� la r�ception d'une requ�te, le serveur proc�de comme suit pour
d�terminer quel serveur virtuel utiliser :</p>
<section id="hashtable"><title>V�rification dans la table de hash</title>
<p>Apr�s que le client se soit connect�, l'adresse
IP � laquelle le client s'est connect� est recherch�e dans la
table de hash IP interne.</p>
<p>Si la r�solution de l'adresse IP n'aboutit pas (adresse IP non
trouv�e), la requ�te est servie par le serveur virtuel
<code>_default_</code> s'il est d�fini pour le port correspondant
� la requ�te. Sinon, elle est servie par le serveur principal.</p>
<p>Si l'adresse IP n'est pas trouv�e dans la table de hash, la
recherche du num�ro de port peut aussi se terminer par une
correspondance � un <code>NameVirtualHost *</code> qui est g�r�
ensuite comme les autres serveur virtuels par noms.</p>
<p>Si une liste est bien trouv�e dans la table pour l'adresse
IP recherch�e, l'�tape suivante est de d�terminer s'il s'agit
d'un serveur virtuel par nom ou par IP.</p>
</section>
<section id="ipbased"><title>Serveur virtuel par IP</title>
<p>Si l'entr�e trouv�e dispose d'une liste de noms vide, c'est
qu'il s'agit d'un serveur virtuel par IP, et aucun autre choix
n'est plus � faire ; la requ�te est servie par ce serveur virtuel.</p>
</section>
<section id="namebased"><title>Serveur virtuel par nom</title>
<p>Si l'entr�e trouv�e correspond � un serveur virtuel par nom,
la liste de noms contient au moins une structure de serveurs
virtuels. Les serveurs virtuels se pr�sentent dans cette liste
dans le m�me ordre que la lecture des directives <code>VirtualHost</code>
dans le fichier de configuration.</p>
<p>Le premier serveur virtuel de cette liste (donc, le premier
serveur virtuel attribu� � une adresse IP donn�e dans le fichier
de configuration) se voit attribuer la plus grande priorit�, ce
qui signifie que c'est lui qui traite les requ�tes pr�sentant un
nom de serveur invalide ou ne pr�sentant pas de champ
<code>Host:</code> dans l'en-t�te.</p>
<p>Si un champ <code>Host:</code> est transmis dans l'en-t�te de
la requ�te, son occurrence est recherch�e dans la liste et le
premier serveur virtuel qui pr�sente un <code>ServerName</code>
ou un <code>ServerAlias</code> correspondant est choisi pour
servir la requ�te. Il est possible que le champ <code>Host:</code>
contienne un num�ro de port, mais Apache utilise toujours le
port sur lequel il a effectivement re�u la requ�te.</p>
un champ d'en-t�te <code>Host:</code>, il est impossible de
d�terminer le serveur auquel le client veut se connecter ; l'URI
de la requ�te est recherch� dans tous les <code>ServerPath</code>
existants. Le premier chemin trouv� est utilis� et la requ�te est
servie par le serveur virtuel correspondant.</p>
<p>Si aucun serveur virtuel n'est trouv�, la requ�te est servie
par le premier serveur virtuel qui �coute sur le port demand� et
qui est sur la liste associ�e � l'adresse IP vers laquelle la
requ�te a �t� envoy�e (comme d�j� pr�cis� ci-avant).</p>
</section>
<section id="persistent"><title>Connexions persistantes</title>
<p>La recherche par adresse IP d�crite ci-avant n'est faite
recherche par nom est r�alis�e pour <em>chaque</em> requ�te au
cours d'une connexion persistante (KeepAlive). En d'autres termes,
il est possible pour un client de faire des requ�tes sur
diff�rents serveurs virtuels par nom, au cours d'une unique
connexion persistante.</p>
</section>
<section id="absoluteURI"><title>URI absolu</title>
<p>Au cas o� l'URI de la requ�te est absolu, et que son nom de
serveur et son port correspondent au serveur principal (ou l'un
des serveurs virtuels configur�s), <em>et</em> qu'ils correspondent
� l'adresse et au port de la requ�te, alors l'URI est amput�
serveur correspondant (principal ou virtuel). Si cette correspondance
n'existe pas, l'URI reste inchang� et la requ�te est consid�r�e
comme une requ�te d'un serveur mandataire (proxy).</p>
</section>
<section id="observations"><title>Observations</title>
<ul>
<li>Les serveurs virtuels par nom et par IP n'interf�rent
jamais entre eux. Les serveurs virtuels par IP ne sont joignables
qu'au travers de leur(s) adresse(s) IP propre(s), en aucun
cas par aucune autre adresse. Les serveurs virtuels par nom
ne sont accessibles que par leur(s) adresse(s) IP qui ne peuvent
�tre d�finies qu'au moyen de la directive
<code>NameVirtualHost</code>.</li>
<li>Les v�rifications sur <code>ServerAlias</code> et
<code>ServerPath</code> ne sont jamais r�alis�es pour les
serveurs virtuels par IP.</li>
<li>L'ordre dans lequel sont agenc�s dans le fichier de
configuration le serveur virtuel <code>_default_</code>, les
serveurs virtuels par nom et par IP, et la directive
<code>NameVirtualHost</code> est sans incidence sur le
fonctionnement. Seul l'ordre des serveurs virtuels par nom
pour une adresse donn�e a une importance. Le serveur virtuel
par nom qui est pr�sent en premier dans la configuration se
voit attribu� la priorit� la plus haute pour les requ�tes
arrivant sur son jeu d'adresses IP.</li>
<li>Pour des raisons de s�curit�, le num�ro de port pr�sent�
dans le champ d'en-t�te <code>Host:</code> n'est jamais utilis�
pour les tests de correspondances. Apache ne prend en compte
que le num�ro de port sur lequel le client a envoy� la requ�te.</li>
<li>Si une directive <code>ServerPath</code> existe, et se
trouve �tre pr�fixe d'une autre directive <code>ServerPath</code>
qui appara�t plus loin dans la configuration, la premi�re
sera toujours utilis�e et la deuxi�me jamais. (Ceci ne se
produit que dans le cas o� aucun champ <code>Host:</code>
n'a �t� pr�sent� par le client pour distinguer les deux.)</li>
<li>Dans le cas o� deux serveurs virtuels par IP ont une
adresse en commun, le serveur virtuel qui appara�t en premier
dans la configuration est toujours choisi. Ce genre de chose
peut arriver par inadvertance. Le serveur envoie une alerte
dans le journal d'erreurs si ce cas se pr�sente.</li>
<li>Le serveur virtuel <code>_default_</code> ne sert la requ�te
que si aucun autre serveur virtuel travaillant sur l'adresse
IP <em>et</em> le port demand�s n'est trouv�. La requ�te n'est
trait�e que si le num�ro de port qui a re�u la requ�te est
associ� au serveur virtuel <code>_default_</code> (qui par
d�faut, correspond � <code>Listen</code>). Un port joker peut
�tre sp�cifi� (<em>comme dans</em> <code>_default_:*</code>)
pour r�cup�rer les requ�tes sur tous les ports ouverts. Ceci
est �galement applicable aux serveurs virtuels
<code>NameVirtualHost *</code>.</li>
<li>Le serveur principal ne sert � servir les requ�tes que
lorsque l'adresse IP et le port demand�s par le client ne
correspondent � aucun serveur virtuel (y compris un serveur
virtuel <code>_default_</code>). En d'autres termes, le serveur
non sp�cifi�es (sauf quand un serveur virtuel <code>_default_</code>
correspond au port).</li>
<li>Ni les serveurs virtuels <code>_default_</code>, ni le
serveur principal ne sont utilis�s pour traiter une requ�te
avec un champ d'en-t�te <code>Host:</code> manquant ou vide
lorsque l'adresse (et le port) de connexion correspondent �
des serveurs virtuels par nom, par exemple, dans une directive
<code>NameVirtualHost</code>.</li>
<li>Il ne faut jamais employer de noms DNS dans des directives
<code>VirtualHost</code>, car cela oblige le serveur a s'appuyer
sur le DNS au moment du d�marrage. De plus, vous vous exposez
� des probl�mes de s�curit� si vous n'avez pas la ma�trise du
DNS pour la totalit� de vos domaines. Voir la documentation
les deux points pr�cis�s ci-apr�s.</li>
<li>Un nom de serveur <code>ServerName</code> devrait toujours
�tre indiqu� pour chaque serveur virtuel. Sans cela, une
r�solution DNS est n�cessaire pour chaque serveur virtuel.</li>
</ul>
</section>
</section>
<section id="tips"><title>Trucs et astuces</title>
<p>En plus des points �voqu�s sur la page des
voici quelques points int�ressants :</p>
<ul>
<li>Toujours positionner les d�finitions relatives au serveur
principal avant toute d�finition <code>VirtualHost</code>.
(Ceci am�liore grandement la lisibilit� de la configuration
-- la mani�re dont la configuration est interpr�t�e apr�s la
lecture des fichiers ne met pas en �vidence le fait que les
d�finitions positionn�es avant et surtout apr�s les serveurs
virtuels peuvent impacter le fonctionnement des serveurs virtuels.)</li>
<li>Toujours regrouper les d�finitions <code>NameVirtualHost</code>
et <code>VirtualHost</code> dans la configuration pour une
meilleure lisibilit�.</li>
<li>�viter les <code>ServerPaths</code> qui sont pr�fixes
d'autres <code>ServerPaths</code>. Si cela ne peut �tre �vit�,
veillez � ce que le serveur virtuel contenant le pr�fixe le plus
long (donc le plus pr�cis) apparaisse dans le fichier de
configuration avant le plus court. (<em>par exemple</em>,
</ul>
</section>
</manualpage>