<?xml version='1.0' encoding='ISO-8859-1' ?>

<!DOCTYPE manualpage SYSTEM "/style/manualpage.dtd">

<?xml-stylesheet type="text/xsl" href="/style/manual.fr.xsl"?>

<manualpage metafile="details.xml.meta">

<parentdocument href="./">Serveurs virtuels</parentdocument>

<title>D�tails sur le fonctionnement des serveurs virtuels</title>

<summary>

<p>Ce document vise � expliquer dans le d�tail comment le serveur

HTTP Apache proc�de lors du choix de l'utilisation

d'un serveur virtuel en fonction d'une requ�te re�ue.</p>

<p>Il est recommand� de lire la documentation<a href="name-based.html#namevip">

Serveurs virtuels � base de nom et serveurs virtuels � base

d'adresse IP</a> pour d�terminer quel type de serveur virtuel nous

convient le mieux, puis de lire les documentations <a

href="name-based.html">serveurs virtuels � base de nom</a> ou <a

href="ip-based.html">serveurs virtuels � base d'adresse IP</a>, et enfin

d'�tudier <a href="examples.html">quelques exemples</a>.</p>

<p>Si vous voulez entrer dans les d�tails, vous pouvez revenir vers

cette page.</p>

</summary>

<seealso><a href="ip-based.html">Support des serveurs virtuels � base

d'adresse IP</a></seealso>

<seealso><a href="name-based.html">Support des serveurs virtuels � base

de nom</a></seealso>

<seealso><a href="examples.html">Exemples de serveurs virtuels pour une

configuration courante</a></seealso>

<seealso><a href="mass.html">H�bergement virtuel de masse configur�

dynamiquement</a></seealso>

<section id="configparsing"><title>Fichier de configuration</title>

<p>Un <em>serveur principal (main_server)</em> contient toutes

les d�finitions qui apparaissent en dehors des sections

<code>&lt;VirtualHost&gt;</code>.</p>

<p>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>Chaque directive <code>VirtualHost</code> comporte une ou

plusieurs adresses et des ports optionnels.</p>

<p>Il est possible d'utiliser des noms d'h�tes dans la d�finition

d'un serveur virtuel, mais ils seront r�solus en adresses IP au

d�marrage du serveur, et si une r�solution de nom �choue, cette

d�finition de serveur virtuel sera ignor�e. Cette m�thode est par

cons�quent d�conseill�e.</p>

<p>L'adresse peut

�tre sp�cifi�e sous la forme <code>*</code>, ce qui conviendra � la

requ�te si aucun autre serveur virtuel ne poss�de l'adresse IP

explicite correspondant � celle de la requ�te.</p>

<p>L'adresse qui appara�t dans la directive <code>VirtualHost</code>

peut �tre associ�e � un port optionnel. Si aucun port n'est

sp�cifi�, il s'agit d'un port g�n�rique qui peut aussi �tre sp�cifi�

comme <code>*</code>. Le port g�n�rique correspond � toutes les

valeurs de port.</p>

<p>(Il ne faut pas confondre les num�ros de port sur lesquels Apache

est en �coute avec les num�ros de port sp�cifi�s dans la directive

<code>VirtualHost</code> ; ces derniers ne servent qu'� d�finir le

<code>serveur virtuel</code> qui sera s�lectionn� pour traiter la

requ�te. Pour d�finir les ports sur lesquels Apache est en �coute,

utilisez la directive <directive module="mpm_common">Listen</directive>).

</p>

<p>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>Apache fait automatiquement sa s�lection � partir de l'en-t�te

HTTP <code>Host</code> fourni par le client, lorsque la

correspondance la plus exacte du point de vue adresse IP/port a lieu

pour plusieurs serveurs virtuels.</p>

<p>La directive <directive module="core">ServerName</directive> peut

appara�tre en quelque endroit de la d�finition d'un serveur.

Cependant, chaque occurrence �crase la pr�c�dente (pour ce serveur).

Si aucune directive <code>ServerName</code> n'est sp�cifi�e, le

serveur tente de d�terminer le nom du serveur � partir de l'adresse

IP.</p>

<p>Le premier serveur virtuel � base de nom apparaissant dans le

fichier de configuration pour une paire IP:port donn�e est

significatif car c'est lui qui sera utilis� pour toutes les requ�tes

re�ues sur cette adresse IP/port et pour laquelle aucun autre

serveur virtuel ne poss�de un ServerName ou un ServerAlias

correspondant. Il sera aussi utilis� pour toutes les connexions SSL

si le serveur ne supporte pas l'<glossary

ref="servernameindication">Indication du nom du serveur</glossary>.</p>

<p>Pour chaque serveur virtuel, diverses valeurs sont initialis�es

par d�faut. En particulier&nbsp;:</p>

<ol>

<li>Dans le cas o� un serveur virtuel ne contient pas de directives

<directive module="core">ServerAdmin</directive>,

<directive module="core">Timeout</directive>,

<directive module="core">KeepAliveTimeout</directive>,

<directive module="core">KeepAlive</directive>,

<directive module="core">MaxKeepAliveRequests</directive>,

<directive module="mpm_common">ReceiveBufferSize</directive>,

ou <directive module="mpm_common">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&nbsp;:</p>

<section id="hashtable"><title>Recherche de l'adresse IP</title>

<p>Lors d'une premi�re connexion sur une adresse/port, le serveur

recherche toutes les directives <code>VirtualHost</code> qui

poss�dent la m�me adresse IP/port.</p>

<p>S'il n'y a aucune correspondance exacte pour cette adresse/port,

la recherche s'effectue sur la valeur g�n�rique (<code>*</code>).</p>

<p>Si aucune correspondance n'est enfin trouv�e, la requ�te sera

servie par le serveur principal.</p>

<p>S'il existe des d�finitions <code>VirtualHost</code> pour

l'adresse IP, l'�tape suivante consiste � d�terminer si nous avons �

faire � un serveur virtuel � base de nom ou d'adresse IP.</p>

</section>

<section id="ipbased"><title>Serveur virtuel par IP</title>

<p>Si une seule section <code>VirtualHost</code> pr�sente la

meilleure correspondance avec la paire adresse IP/port, aucune

action n'est entreprise et la requ�te est

trait�e par le serveur virtuel qui correspond.</p>

</section>

<section id="namebased"><title>Serveur virtuel par nom</title>

<p>Si plusieurs sections <code>VirtualHost</code> pr�sentent la

meilleure correspondance avec la paire adresse IP/port, le terme

"liste" dans les �tapes suivantes fait r�f�rence � la liste des

serveurs virtuels qui correspondent, selon l'ordre dans lequel ils

apparaissent dans le fichier de configuration.</p>

<p>Si la connexion utilise SSL, si le serveur supporte l'<glossary

ref="servernameindication">Indication de nom de serveur</glossary>,

et si la n�gociation du client SSL inclut l'extension TLS dans le

nom d'h�te requis, alors ce nom d'h�te sera utilis� par la suite, tout

comme un en-t�te <code>Host:</code> aurait �t� utilis� dans le cas

d'une connexion non-SSL. Si ces conditions ne sont pas r�unies, le

premier serveur virtuel � base de nom dont l'adresse correspond sera

utilis� pour les connexions SSL. Ceci est important car c'est le

serveur virtuel qui d�termine quel certificat le serveur va utiliser

pour la connexion.</p>

<p>Si la requ�te contient un en-t�te <code>Host:</code>, on

recherche dans la liste le premier serveur virtuel dont le

<code>ServerName</code> ou le <code>ServerAlias</code> correspond,

et c'est celui-ci qui va traiter la requ�te. Un en-t�te

<code>Host:</code> peut comporter un num�ro de port mais Apache

l'ignore syst�matiquement et utilise toujours le

port sur lequel il a effectivement re�u la requ�te.</p>

<p>Le premier serveur virtuel du fichier de configuration qui

poss�de l'adresse sp�cifi�e est prioritaire et intercepte toutes les

requ�tes � destination d'un nom de serveur inconnu, ou toute requ�te

sans en-t�te <code>Host:</code> (comme les requ�tes HTTP/1.0).</p>

</section>

<section id="persistent"><title>Connexions persistantes</title>

<p>La <em>recherche par adresse IP</em> d�crite ci-avant n'est faite

qu'<em>une fois</em> pour chaque session TCP/IP, alors que la

<em>recherche par nom</em> 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�

de son pr�fixe protocole/nom de serveur/port et trait� par le

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>La s�lection d'un serveur virtuel en fonction de son nom est

un processus qui intervient apr�s la s�lection par le serveur du

serveur virtuel qui correspond le mieux du point de vue adresse

IP/port.</li>

<li>Si vous ne tenez pas compte de l'adresse IP � laquelle le

client s'est connect�, indiquez un caract�re "*" comme adresse

pour tous les serveurs virtuels, et la s�lection du serveur

virtuel en fonction du nom s'appliquera alors � tous les serveurs

virtuels d�finis.</li>

<li>Les v�rifications sur <code>ServerName</code> et

<code>ServerAlias</code> ne sont jamais

r�alis�es pour les serveurs virtuels par IP.</li>

<li>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>Le num�ro de port contenu dans l'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 deux serveurs virtuels partagent la m�me adresse, la

s�lection se fera implicitement sur le nom. Il s'agit d'une

nouvelle fonctionnalit� de la version 2.3.11.</li>

<li>Le serveur principal ne sert 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>*</code>). En d'autres termes, le serveur

principal n'est utile que pour les combinaisons adresse/port

non sp�cifi�es (sauf quand un serveur virtuel <code>_default_</code>

correspond au port).</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

<a href="/dns-caveats.html">disponible ici</a>, ainsi que

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

<a href="/dns-caveats.html#tips">probl�mes li�s au DNS</a>,

voici quelques points int�ressants&nbsp;:</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 de tous les

serveurs virtuels.)</li>

</ul>

</section>

</manualpage>