Serveur Apache HTTP Version 2.2
Ce document d�crit quand et comment utiliser des serveurs virtuels par nom.
Les h�bergements virtuels par IP utilisent l'adresse IP de la connexion afin de d�terminer quel serveur virtuel doit r�pondre. Par cons�quent, vous devez disposer d'adresses IP diff�rentes pour chaque serveur. Avec un h�bergement virtuel par nom, le serveur s'appuit sur les informations transmises par le client dans les en-t�tes HTTP de ses requ�tes. La technique pr�sent�e ici vous permet de disposer de serveurs virtuels diff�rents partag�s sur une m�me adresse IP.
L'h�bergement virtuel par nom est habituellement plus simple,
car il vous suffit de configurer votre serveur DNS pour que
chaque domaine pointe sur l'adresse IP dont vous disposez, et de
configurer votre serveur Apache HTTP afin qu'il reconnaisse
ces domaines. Il r�duit aussi la p�nurie en adresses IP. Par
cons�quent, vous devriez utiliser l'h�bergement virtuel par
nom, sauf dans le cas o� vous utiliseriez des �quipements qui
n�cessitent un h�bergement bas� sur IP. Les raisons historiques de
l'h�bergement bas� sur IP dans un but de support de certains clients ne
s'appliquent plus � un serveur web d'usage g�n�ral, sauf si vous
utilisez une version de mod_ssl
sans support SNI
(situation standard depuis la version 2.2.12 d'Apache).
Modules Apparent�s | Directives Apparent�es |
---|---|
Pour utiliser des serveurs virtuels par nom, vous devez
d�signer l'adresse IP (et si possible le port) sur le serveur
devant accepter les requ�tes pour des domaines. Cette
configuration utilise la directive
NameVirtualHost
. Dans un
cas normal o� n'importe quelle adresse IP peut �tre utilis�e,
vous pouvez ajouter *
comme argument de la directive
NameVirtualHost
. Si vous
pr�voyez d'utiliser de multiples ports (comme l'emploi de SSL),
vous devriez ajouter le port � cet argument tel que
*:80
. Notez que la simple mention d'une adresse
IP dans une directive
NameVirtualHost
ne suffit
pas � faire �couter le serveur sur cette IP. Consultez
D�finition des adresses et ports qu'utilise
Apache pour plus
de d�tails. Par ailleurs, chaque adresse IP sp�cifi�e ici doit
�tre associ�e avec une interface r�seau sur le serveur.
L'�tape suivante est la cr�ation d'une section
<VirtualHost>
pour chacun des serveurs � cr�er. L'argument de la directive
<VirtualHost>
doit �tre le m�me que celui de la directive
NameVirtualHost
(dans le cas pr�sent "*:80"). Dans chaque section
<VirtualHost>
,
vous devez d�finir au minimum une directive
ServerName
pour d�signer
le serveur concern� et une directive
DocumentRoot
pour pr�ciser
l'emplacement sur le syst�me de fichiers du contenu de ce serveur.
Si vous ajoutez des serveurs virtuels � un serveur Web
existant, vous devez �galement cr�er une section
<VirtualHost>
red�finissant ce serveur existant. Les directives
ServerName
et
DocumentRoot
incluses
dans ce serveur virtuel doivent �tre les m�mes que pour
les directives globales
ServerName
et
DocumentRoot
. Positionnez
ce serveur virtuel en premier dans le fichier de configuration
pour en faire le serveur par d�faut.
Par exemple, supposez que vous h�bergez le domaine
www.domain.tld
et que vous souhaitez ajouter le
serveur virtuel www.otherdomain.tld
qui pointe sur
la m�me adresse IP. Il vous suffit d'ajouter la configuration
suivante � httpd.conf
:
NameVirtualHost *:80
<VirtualHost *:80>
ServerName www.domain.tld
ServerAlias domain.tld *.domain.tld
DocumentRoot /www/domain
</VirtualHost>
<VirtualHost *:80>
ServerName www.otherdomain.tld
DocumentRoot /www/otherdomain
</VirtualHost>
Autrement, vous pouvez sp�cifiez une adresse IP explicite
� la place de *
dans les deux directives
NameVirtualHost
et
<VirtualHost>
.
Par exemple, cette m�thode est utile si vous souhaitez faire
tourner quelques serveurs virtuels par nom sur une m�me adresse
IP, et d'autres, soit par IP, soit bas�s sur un autre jeu de
serveurs virtuels par nom sur une autre adresse IP.
Plusieurs serveurs sont accessibles par plus d'un nom. Il
suffit de placer la directive
ServerAlias
dans une section
<VirtualHost>
.
Par exemple, dans la premi�re section
<VirtualHost>
ci-dessus, la directive ServerAlias
indique aux utilisateurs les autres noms permis pour acc�der au
m�me site Web :
ServerAlias domain.tld *.domain.tld
ainsi, toutes les requ�tes portant sur un domaine
domain.tld
seront servies par le serveur virtuel
www.domain.tld
. Les caract�res joker *
et ?
peuvent �tre utilis�s pour les correspondances.
Bien entendu, vous ne pouvez pas inventer des noms et les placer
dans une directive ServerName
ou ServerAlias
. Tout d'abord, votre serveur DNS
doit �tre correctement configur� pour lier ces noms � une
adresse IP associ�e avec votre serveur.
La liste compl�te des noms dans la section VirtualHost
sont trait�s comme une
directive ServerAlias
sans
caract�res g�n�riques.
Finalement, vous pouvez affiner la configuration des serveurs
virtuels en pla�ant d'autres directives � l'int�rieur des sections
<VirtualHost>
.
La plupart des directives peut �tre plac�e dans ces sections en
y changeant seulement la configuration du serveur virtuel associ�.
Pour d�terminer si une directive particuli�re est permise,
consultez le contexte de la
directive. Le jeu de directives configur�es dans le contexte
du serveur principal (en dehors de toutes sections
<VirtualHost>
)
sera utilis� seulement s'il n'y a pas de configuration contraire
par un serveur virtuel.
Maintenant, lorsqu'une requ�te arrive, le serveur va d'abord
tester si elle utilise une adresse IP qui correspond �
NameVirtualHost
. Si c'est
le cas, il regardera chaque section
<VirtualHost>
avec l'adresse correspondante et essaiera d'en trouver une o�
le nom de domaine requis correspond �
ServerName
ou
ServerAlias
. S'il en trouve une, il utilisera
sa configuration pour le serveur. Si aucun serveur virtuel ne
correspond, alors le premier serveur virtuel list�
dont l'adresse IP correspond sera employ�.
En cons�quence, le premier serveur virtuel list� est le
serveur virtuel par d�faut. La directive
DocumentRoot
du
serveur principal ne sera
jamais employ�e lorsqu'une adresse IP
correspond � la directive
NameVirtualHost
. Si vous
souhaitez avoir une configuration sp�ciale pour les requ�tes
qui ne correspondent pas � un serveur virtuel en particulier,
mettez cette configuration dans une section
<VirtualHost>
que vous placerez en premier dans le fichier de configuration.
Comme mentionn� plus t�t, certains clients ne transmettent pas les donn�es n�cessaires pour le bon fonctionnement des serveurs virtuels par nom. Ces clients recevront toujours les pages du premier serveur virtuel list� pour cette adresse IP (le serveur virtuel par nom primaire).
Veuillez noter que quand nous disons plus anciens, nous
disons vraiment plus anciens. Vous avez peu de chances de rencontrer
de tels navigateurs encore utilis�s de nos jours. Toutes les
versions actuelles des navigateurs transmettent leur en-t�te
Host
comme exig� par les serveurs virtuels par nom.
Il existe une solution avec la directive
ServerPath
, bien que
l�g�rement complexe :
Exemple de configuration :
NameVirtualHost 111.22.33.44
<VirtualHost 111.22.33.44>
ServerName www.domain.tld
ServerPath /domain
DocumentRoot /web/domain
</VirtualHost>
Qu'est-ce que cela signifie ? Il signifie qu'une requ�te
pour tout URI qui commence par "/domain
" sera
servie par le serveur virtuel www.domain.tld
.
Ainsi, les pages sont accessibles �
http://www.domain.tld/domain/
pour tous les
clients, bien que ceux qui transmettent un en-t�te
Host:
peuvent �galement y acc�der �
http://www.domain.tld/
.
Pour rendre cette technique fonctionnelle, mettez un lien
dans votre serveur virtuel primaire vers
http://www.domain.tld/domain/
. Ensuite, dans les
pages de ce serveur virtuel, assurez vous de n'utiliser que
des liens relatifs (par exemple, "file.html
"
ou "../icons/image.gif
") ou des liens contenant
le pr�fixe /domain/
(par exemple,
"http://www.domain.tld/domain/misc/file.html
"
ou "/domain/misc/file.html
").
Cela requiert un peu de discipline, mais si vous suivez cette ligne de conduite, vous serez assur� que vos pages s'afficheront dans tous les navigateurs, nouveaux et anciens.