D�tails sur le fonctionnement des serveurs virtuels

Fichier de configuration

Un serveur principal (main_server) contient toutes les d�finitions qui apparaissent en dehors des sections <VirtualHost>.

Les serveurs virtuels, aussi appel�s vhosts (pour virtual hosts), sont d�finis par les sections <VirtualHost>.

Chaque directive VirtualHost comporte une ou plusieurs adresses et des ports optionnels.

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.

L'adresse peut �tre sp�cifi�e sous la forme *, ce qui conviendra � la requ�te si aucun autre serveur virtuel ne poss�de l'adresse IP explicite correspondant � celle de la requ�te.

L'adresse qui appara�t dans la directive VirtualHost 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 *. Le port g�n�rique correspond � toutes les valeurs de port.

(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 VirtualHost ; ces derniers ne servent qu'� d�finir le serveur virtuel qui sera s�lectionn� pour traiter la requ�te. Pour d�finir les ports sur lesquels Apache est en �coute, utilisez la directive Listen).

L'ensemble des adresses (y compris les r�sultats multiples A issus des requ�tes DNS) est appel� jeu d'adresses du serveur virtuel.

Apache fait automatiquement sa s�lection � partir de l'en-t�te HTTP Host fourni par le client, lorsque la correspondance la plus exacte du point de vue adresse IP/port a lieu pour plusieurs serveurs virtuels.

La directive ServerName 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 ServerName n'est sp�cifi�e, le serveur tente de d�terminer le nom du serveur � partir de l'adresse IP.

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'Indication du nom du serveur.

Tous les noms sp�cifi�s au sein d'une section VirtualHost sont trait�s comme un ServerAlias (sans caract�res g�n�riques), mais ne sont �cras�s par aucune directive ServerAlias.

Pour chaque serveur virtuel, diverses valeurs sont initialis�es par d�faut. En particulier :

1. Dans le cas o� un serveur virtuel ne contient pas de directives ServerAdmin, Timeout, KeepAliveTimeout, KeepAlive, MaxKeepAliveRequests, ReceiveBufferSize, ou SendBufferSize, 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.)
2. 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.
3. Les configurations par serveur pour chaque module sont assembl�es � partir de celles du serveur principal.

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.

Dans le cas o� le serveur principal n'a pas de ServerName � ce stade, le nom de la machine sur laquelle tourne le programme httpd est utilis� � sa place. Nous appellerons jeu d'adresses du serveur principal les adresses IP renvoy�es par une r�solution DNS sur le ServerName du serveur principal.

Pour tous les champs ServerName 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 VirtualHost qui d�finit le serveur virtuel.

Si un serveur virtuel contient la valeur magique _default_, il fonctionne sur le m�me ServerName que le serveur principal.

Choix du serveur virtuel

� la r�ception d'une requ�te, le serveur proc�de comme suit pour d�terminer quel serveur virtuel utiliser :

Recherche de l'adresse IP

Lors d'une premi�re connexion sur une adresse/port, le serveur recherche toutes les directives VirtualHost qui poss�dent la m�me adresse IP/port.

S'il n'y a aucune correspondance exacte pour cette adresse/port, la recherche s'effectue sur la valeur g�n�rique (*).

Si aucune correspondance n'est enfin trouv�e, la requ�te sera servie par le serveur principal.

S'il existe des d�finitions VirtualHost pour l'adresse IP, l'�tape suivante consiste � d�terminer si nous avons � faire � un serveur virtuel � base de nom ou d'adresse IP.

Serveur virtuel par IP

Si une seule section VirtualHost 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.

Serveur virtuel par nom

Si plusieurs sections VirtualHost 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.

Si la connexion utilise SSL, si le serveur supporte l'Indication de nom de serveur, 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 Host: 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.

Si la requ�te contient un en-t�te Host:, on recherche dans la liste le premier serveur virtuel dont le ServerName ou le ServerAlias correspond, et c'est celui-ci qui va traiter la requ�te. Un en-t�te Host: 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.

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 Host: (comme les requ�tes HTTP/1.0).

Connexions persistantes

La recherche par adresse IP d�crite ci-avant n'est faite qu'une fois pour chaque session TCP/IP, alors que la recherche par nom est r�alis�e pour chaque 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.

URI absolu

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), et 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).

Observations

• 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.
• 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.
• Les v�rifications sur ServerName et ServerAlias ne sont jamais r�alis�es pour les serveurs virtuels par IP.
• 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.
• Le num�ro de port contenu dans l'en-t�te Host: 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.
• 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.
• 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 *). 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 _default_ correspond au port).
• Il ne faut jamais employer de noms DNS dans des directives VirtualHost, 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 disponible ici, ainsi que les deux points pr�cis�s ci-apr�s.
• Un nom de serveur ServerName devrait toujours �tre indiqu� pour chaque serveur virtuel. Sans cela, une r�solution DNS est n�cessaire pour chaque serveur virtuel.

Trucs et astuces

En plus des points �voqu�s sur la page des probl�mes li�s au DNS, voici quelques points int�ressants :

• Toujours positionner les d�finitions relatives au serveur principal avant toute d�finition VirtualHost. (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.)