X-Git-Url: https://granicus.if.org/sourcecode?a=blobdiff_plain;f=docs%2Fmanual%2Fvhosts%2Fname-based.html.fr;h=17afb28e838a8a9a229d6bc31d772e3f0d0a3b04;hb=35d82cdd2dff0b108ee0884dc65b06833806fa5b;hp=961994494cfa15623fa9871c2ceca131922433a1;hpb=bd1e90ea81b04c129b19f50db5a39c5163ccfa92;p=apache diff --git a/docs/manual/vhosts/name-based.html.fr b/docs/manual/vhosts/name-based.html.fr index 961994494c..17afb28e83 100644 --- a/docs/manual/vhosts/name-based.html.fr +++ b/docs/manual/vhosts/name-based.html.fr @@ -8,40 +8,48 @@ Support Apache des serveurs virtuels par nom - Serveur Apache HTTP - + + +
<-
-Apache > Serveur HTTP > Documentation > Version 2.3 > Serveurs virtuels

Support Apache des serveurs virtuels par nom

+Apache > Serveur HTTP > Documentation > Version 2.5 > Serveurs virtuels

Support Apache des serveurs virtuels par nom

Langues Disponibles:  de  |  en  |  fr  |  ja  | - ko 

+ ko  | + tr 

+
Cette traduction peut être périmée. Vérifiez la version + anglaise pour les changements récents.

Ce document décrit quand et comment utiliser des serveurs virtuels par nom.

+

Voir aussi

top

Serveurs virtuels par nom vs. par IP

-

Les hébergements virtuels par IP utilisent l'adresse IP +

Les serveurs 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 nom de domaine complet (FQDN) que vous hébergez. - Avec un hébergement - virtuel par nom, le serveur s'appuit sur les informations + différentes pour chaque serveur.

+ +

Avec un hébergement + virtuel par nom, le serveur s'appuie 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.

@@ -52,62 +60,58 @@ 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 à moins d'avoir une raison spécifique de préférer - l'hébergement virtuel par IP. Certaines de ces raisons vous - sont exposées ci-après :

- - +
top
+
+

Comment le serveur sélectionne-t-il le serveur +virtuel basé sur le nom approprié

+ +

Il est important de savoir que la première étape de la résolution + de serveur virtuel basée sur le nom est une résolution basée sur IP. + La résolution de serveur virtuel basée sur le nom ne fait que + choisir le serveur virtuel basé sur le nom le plus approprié, en se + limitant aux candidats qui conviennent le mieux du point de vue IP. + La résolution basée sur IP est sans objet si l'on + utilise un caractère générique (*) pour l'adresse IP dans + toutes les directives VirtualHost.

+ +

A l'arrivée d'une requête, le serveur va rechercher l'argument de + section <VirtualHost> présentant la meilleure + (la plus exacte) correspondance avec la paire adresse IP/port + utilisée dans la requête. Si plusieurs serveurs virtuels possèdent + cette même paire adresse IP/port, Apache va ensuite comparer les + valeurs des directives ServerName et module="core">ServerAlias avec le nom de serveur + présent dans la requête.

+ +

Le serveur virtuel à base de nom + par défaut pour une paire adresse IP/port

+

Si aucune directive ServerName ou ServerAlias ne correspond dans + la liste de serveurs virtuels présentant la meilleure correspondance + du point de vue adresse IP/port, c'est le premier serveur + virtuel de cette liste qui sera utilisé.

+
top

Utilisation de serveurs virtuels par nom

- + -

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 - la page sur les liaisons 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 + +

La première étape consiste à créer une section <VirtualHost> - doit être le même que celui de la directive - NameVirtualHost - (c'est-à-dire l'adresse IP ou * pour toutes les - adresses). Dans chaque section + pour chacun des serveurs à définir. Dans chaque section <VirtualHost>, vous devez définir au minimum une directive ServerName pour désigner @@ -116,47 +120,49 @@ l'emplacement sur le système de fichiers du contenu de ce serveur.

Le serveur principal disparaît

-

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.

+

Toute requête qui ne correspond à aucune section <VirtualHost> existante + est traitée avec la configuration du serveur principal, sans + tenir compte du nom d'hôte ou de la directive ServerName.

+ +

Lorsque vous ajoutez un serveur virtuel basé sur le nom à un + serveur existant, et si les caractéristiques de ce serveur + virtuel correspondent à des combinaisons IP/port préexistantes, + les requêtes seront alors traitées par un serveur virtuel + explicite. Dans ce cas, il est en général judicieux de créer un + serveur virtuel par défaut + comportant une directive ServerName correspondant au nom du + serveur principal. De nouveaux domaines sur les mêmes interface + et port, mais nécessitant des configurations distinctes, + pourront alors être ajoutés en tant que serveurs virtuels + spécifiques (et non 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 + www.example.com et que vous souhaitez ajouter le + serveur virtuel other.example.com 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
+ # Le premier serveur virtuel de la liste est aussi le + # serveur par défaut pour *:80 + ServerName www.example.com
+ ServerAlias example.com
DocumentRoot /www/domain
</VirtualHost>

<VirtualHost *:80>
- ServerName www.otherdomain.tld
+ ServerName other.example.com
DocumentRoot /www/otherdomain
</VirtualHost>

Autrement, vous pouvez spécifiez une adresse IP explicite - à la place de * dans les deux directives - NameVirtualHost et + à la place de * dans la directive <VirtualHost>. Par exemple, cette méthode est utile si vous souhaitez faire tourner quelques serveurs virtuels par nom sur une même adresse @@ -174,12 +180,12 @@ même site Web :

- ServerAlias domain.tld *.domain.tld + ServerAlias example.com *.example.com

ainsi, toutes les requêtes portant sur un domaine - domain.tld seront servies par le serveur virtuel - www.domain.tld. Les caractères joker * + example.com seront servies par le serveur virtuel + www.example.com. 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 @@ -187,112 +193,57 @@ doit être correctement configuré pour lier ces noms à une adresse IP associée avec votre serveur.

+

La recherche du serveur virtuel à base de nom qui correspond au + plus près à la requête s'effectue parmi les <virtualhost> selon leur + ordre d'apparition dans le fichier de configuration. Le premier + serveur virtuel dont le ServerName ou le ServerAlias correspond est utilisé, sans + priorité particulière en cas de présence de caractères génériques + (que ce soit pour le ServerName ou le ServerAlias).

+

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 la page de - contexte. Le jeu de directives configurées dans le contexte + 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 default. La directive - DocumentRoot du - serveur principal ne sera - jamais employée lorsqu'une adresse IP - correspond dans une directive - NameVirtualHost. Si vous - ne voulez pas avoir de configuration spéciale pour les requêtes - qui ne sont pas attachées à un serveur virtuel en particulier, - mettez cette configuration dans une section - <VirtualHost> - que vous placerez en premier dans le fichier de configuration.

- -
top
-
-

Compatibilité avec les navigateurs anciens

- -

Comme mentionné plus tôt, certains clients ne transmettent - pas les données nécessaires pour le bon fonctionnement des - serveurs virtuels. Ces clients recevront toujours les pages - du premier serveur virtuel listé pour cette adresse IP (le - serveur virtuel par nom primaire).

- -

De combien plus anciens ?

-

Veuillez noter que quand nous disons plus anciens, nous - disons vraiment plus anciens. Vous seriez malchanceux 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 ne 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.

-

Langues Disponibles:  de  |  en  |  fr  |  ja  | - ko 

-
+ ko  | + tr 

+
top

Commentaires

This section is experimental!
Comments placed here should not be expected +to last beyond the testing phase of this system, nor do we in any way guarantee that we'll read them.
+
\ No newline at end of file