D�tails sur le fonctionnement des serveurs virtuels

Interpr�tation des fichiers 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>.

Les directives Listen, ServerName, ServerPath, et ServerAlias 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).

La valeur par d�faut du champ Listen pour le serveur principal est de 80. Le serveur principal n'a pas de valeur par d�faut pour ServerPath ni pour ServerAlias. La valeur par d�faut de ServerName est d�duite � partir de l'adresses IP du serveur.

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.

� la diff�rence du serveur principal, les ports des serveurs virtuels n'affectent pas les ports sur lesquels Apache se met � l'�coute.

Chaque adresse incluse dans une directive VirtualHost peut disposer d'un port optionnel. Si le port n'est pas pr�cis�, il prend par d�faut la derni�re valeur de Listen lue dans la configuration du serveur principal. Le port particulier * repr�sente un joker qui correspond � tous les ports. L'ensemble des adresses (y compris les r�sultats multiples A issus des requ�tes DNS) est appel� jeu d'adresses du serveur virtuel.

� moins qu'une directive NameVirtualHost ne soit utilis�e pour une adresse IP sp�cifique, le premier serveur virtuel avec cette adresse est consid�r� comme un serveur virtuel par-IP. L'adresse IP peut �galement prendre la valeur joker *.

Dans les cas o� l'on souhaite utiliser un serveur virtuel par nom, la directive NameVirtualHost doit 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 NameVirtualHost.

On peut utiliser plusieurs directives NameVirtualHost pour un groupe de directives VirtualHost, mais seule une directive NameVirtualHost doit �tre utilis�e pour chaque couple IP:port donn�.

L'ordre d'apparition des directives NameVirtualHost et VirtualHost est sans importance, ce qui fait que les deux exemples suivants ont des effets identiques (seul l'ordre des directives VirtualHost pour un jeu d'adresses est important, voir ci-dessous) :

NameVirtualHost 111.22.33.44 <VirtualHost 111.22.33.44> # serveur A ... </VirtualHost> <VirtualHost 111.22.33.44> # serveur B ... </VirtualHost> NameVirtualHost 111.22.33.55 <VirtualHost 111.22.33.55> # serveur C ... </VirtualHost> <VirtualHost 111.22.33.55> # serveur D ... </VirtualHost>

<VirtualHost 111.22.33.44> # serveur A </VirtualHost> <VirtualHost 111.22.33.55> # serveur C ... </VirtualHost> <VirtualHost 111.22.33.44> # serveur B ... </VirtualHost> <VirtualHost 111.22.33.55> # serveur D ... </VirtualHost> NameVirtualHost 111.22.33.44 NameVirtualHost 111.22.33.55

(Il est conseill� d'adopter le choix de gauche pour faciliter la lisibilit� des fichiers de configuration.)

Apr�s la lecture de la directive VirtualHost, le serveur virtuel se voit attribuer une valeur Listen par d�faut qui est la valeur du port associ� au premier nom sp�cifi� dans sa directive VirtualHost.

La liste compl�te des noms d'une directive VirtualHost est g�r�e exactement comme des ServerAlias (mais ne sont pas �cras�s par d'autres ServerAlias) si tous les noms sont r�solus dans ce jeu d'adresse. � noter que les �tats Listen de ce serveur virtuel sont sans incidence sur les ports attibu�s au jeu d'adresses.

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 NameVirtualHost, cette liste contient les noms des serveurs virtuels pour cette adresse. Si aucun serveur virtuel n'est d�fini pour cette adresse, la directive NameVirtualHost 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.

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.

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, ResourceConfig, AccessConfig, Timeout, KeepAliveTimeout, KeepAlive, MaxKeepAliveRequests, 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 :

V�rification dans la table de hash

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.

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 _default_ s'il est d�fini pour le port correspondant � la requ�te. Sinon, elle est servie par le serveur principal.

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 NameVirtualHost * qui est g�r� ensuite comme les autres serveur virtuels par noms.

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.

Serveur virtuel par IP

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.

Serveur virtuel par nom

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 VirtualHost dans le fichier de configuration.

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 Host: dans l'en-t�te.

Si un champ Host: 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 ServerName ou un ServerAlias correspondant est choisi pour servir la requ�te. Il est possible que le champ Host: contienne un num�ro de port, mais Apache utilise toujours le port sur lequel il a effectivement re�u la requ�te.

Dans le cas o� le client a envoy� une requ�te en HTTP/1.0 sans un champ d'en-t�te Host:, 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 ServerPath existants. Le premier chemin trouv� est utilis� et la requ�te est servie par le serveur virtuel correspondant.

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

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

• 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 NameVirtualHost.
• Les v�rifications sur ServerAlias et ServerPath ne sont jamais r�alis�es pour les serveurs virtuels par IP.
• L'ordre dans lequel sont agenc�s dans le fichier de configuration le serveur virtuel _default_, les serveurs virtuels par nom et par IP, et la directive NameVirtualHost 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.
• Pour des raisons de s�curit�, le num�ro de port pr�sent� dans le champ d'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 une directive ServerPath existe, et se trouve �tre pr�fixe d'une autre directive ServerPath 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 Host: n'a �t� pr�sent� par le client pour distinguer les deux.)
• 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.
• Le serveur virtuel _default_ ne sert la requ�te que si aucun autre serveur virtuel travaillant sur l'adresse IP et 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 _default_ (qui par d�faut, correspond � Listen). Un port joker peut �tre sp�cifi� (comme dans _default_:*) pour r�cup�rer les requ�tes sur tous les ports ouverts. Ceci est �galement applicable aux serveurs virtuels NameVirtualHost *.
• 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 _default_). 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).
• Ni les serveurs virtuels _default_, ni le serveur principal ne sont utilis�s pour traiter une requ�te avec un champ d'en-t�te Host: manquant ou vide lorsque l'adresse (et le port) de connexion correspondent � des serveurs virtuels par nom, par exemple, dans une directive NameVirtualHost.
• 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 des serveurs virtuels.)
• Toujours regrouper les d�finitions NameVirtualHost et VirtualHost dans la configuration pour une meilleure lisibilit�.
• �viter les ServerPaths qui sont pr�fixes d'autres ServerPaths. 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. (par exemple, "ServerPath /abc" est � sp�cifier apr�s "ServerPath /abc/def").