Delivered-To: mailing list cvs@httpd.apache.org Received: (qmail 3396 invoked by uid 99); 29 Jun 2005 08:54:19 -0000 X-ASF-Spam-Status: No, hits=0.3 required=10.0 tests=NORMAL_HTTP_TO_IP,NO_REAL_NAME X-Spam-Check-By: apache.org Received: from [209.237.227.194] (HELO minotaur.apache.org) (209.237.227.194) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 29 Jun 2005 01:54:14 -0700 Received: (qmail 70664 invoked by uid 65534); 29 Jun 2005 08:54:12 -0000 Message-ID: <20050629085412.70663.qmail@minotaur.apache.org> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: svn commit: r202339 [1/3] - /httpd/httpd/trunk/docs/manual/vhosts/ Date: Wed, 29 Jun 2005 08:54:10 -0000 To: cvs@httpd.apache.org From: jfclere@apache.org X-Mailer: svnmailer-1.0.2 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Author: jfclere Date: Wed Jun 29 01:54:09 2005 New Revision: 202339 URL: http://svn.apache.org/viewcvs?rev=202339&view=rev Log: Submitted and reviewed by Vincent Deffontaines, alain B and Jean-François El Fouly. Added: httpd/httpd/trunk/docs/manual/vhosts/details.html.fr httpd/httpd/trunk/docs/manual/vhosts/details.xml.fr httpd/httpd/trunk/docs/manual/vhosts/examples.html.fr httpd/httpd/trunk/docs/manual/vhosts/examples.xml.fr httpd/httpd/trunk/docs/manual/vhosts/fd-limits.html.fr httpd/httpd/trunk/docs/manual/vhosts/fd-limits.xml.fr httpd/httpd/trunk/docs/manual/vhosts/index.html.fr httpd/httpd/trunk/docs/manual/vhosts/index.xml.fr httpd/httpd/trunk/docs/manual/vhosts/ip-based.html.fr httpd/httpd/trunk/docs/manual/vhosts/ip-based.xml.fr httpd/httpd/trunk/docs/manual/vhosts/name-based.html.fr httpd/httpd/trunk/docs/manual/vhosts/name-based.xml.fr Added: httpd/httpd/trunk/docs/manual/vhosts/details.html.fr URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/docs/manual/vhosts/details.html.fr?rev=202339&view=auto ============================================================================== --- httpd/httpd/trunk/docs/manual/vhosts/details.html.fr (added) +++ httpd/httpd/trunk/docs/manual/vhosts/details.html.fr Wed Jun 29 01:54:09 2005 @@ -0,0 +1,459 @@ + + + +Détails sur le fonctionnement des serveurs virtuels - Serveur Apache HTTP + + + + + +

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

Détails sur le fonctionnement des serveurs virtuels

Langues Disponibles: en | + fr | + ko

Cette traduction peut être périmée. Verifiez la version + Anglaise pour les changements récents.

+ + +

Le code gérant les serveurs virtuels a été réécrit à partir de + zéro dans Apache 1.3. Ce document vise à expliquer + dans le détail comment Apache procède lors du choix de l'utilisation + d'un serveur virtuel en fonction d'une requête reçue. L'apparition + de la directive NameVirtualHost + a rendu beaucoup plus facile et plus sûre la configuration des + serveurs virtuels par rapport aux versions précédant la 1.3.

+ +

Si vous voulez juste que ça marche sans en + comprendre le fonctionnement, voici quelques + exemples.

+ +

Interprétation des fichiers +de configuration
Choix du serveur virtuel
Trucs et astuces

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 :

+ +

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

+ +

Langues Disponibles: en | + fr | + ko

+ \ No newline at end of file Added: httpd/httpd/trunk/docs/manual/vhosts/details.xml.fr URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/docs/manual/vhosts/details.xml.fr?rev=202339&view=auto ============================================================================== --- httpd/httpd/trunk/docs/manual/vhosts/details.xml.fr (added) +++ httpd/httpd/trunk/docs/manual/vhosts/details.xml.fr Wed Jun 29 01:54:09 2005 @@ -0,0 +1,448 @@ + + + + + + + + + +Serveurs virtuels + Détails sur le fonctionnement des serveurs virtuels + +

+ +

Le code gérant les serveurs virtuels a été réécrit à partir de + zéro dans Apache 1.3. Ce document vise à expliquer + dans le détail comment Apache procède lors du choix de l'utilisation + d'un serveur virtuel en fonction d'une requête reçue. L'apparition + de la directive NameVirtualHost + a rendu beaucoup plus facile et plus sûre la configuration des + serveurs virtuels par rapport aux versions précédant la 1.3.

+ +

Si vous voulez juste que ça marche sans en + comprendre le fonctionnement, voici quelques + exemples.

+ +

Interprétation des fichiers +de configuration + +

+ +

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 différence du serveur principal, les ports des serveurs + virtuels n'affectent pas les ports sur lesquels + Apache se met à l'écoute.

+ +

À 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 *.

+ +

+ + + + +

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

+ +

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

+ +

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.)
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.
Les configurations par serveur pour chaque module sont assemblées + à partir de celles du serveur principal.

+ +

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.

+ +

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 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 + +

+ +

Connexions persistantes + +

+ +

URI absolu + +

+ +

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

+ +

+ + Added: httpd/httpd/trunk/docs/manual/vhosts/examples.html.fr URL: http://svn.apache.org/viewcvs/httpd/httpd/trunk/docs/manual/vhosts/examples.html.fr?rev=202339&view=auto ============================================================================== --- httpd/httpd/trunk/docs/manual/vhosts/examples.html.fr (added) +++ httpd/httpd/trunk/docs/manual/vhosts/examples.html.fr Wed Jun 29 01:54:09 2005 @@ -0,0 +1,681 @@ + + + +Exemples d'utilisations de VirtualHost - Serveur Apache HTTP + + + + + +

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

Exemples d'utilisations de VirtualHost

Langues Disponibles: en | + fr | + ja | + ko

Cette traduction peut être périmée. Verifiez la version + Anglaise pour les changements récents.

+ + +

Le but de ce document est d'essayer de répondre aux questions + les plus répandues sur la configuration des serveurs virtuels. + Les scénarios présentés ici se rencontrent quand plusieurs + serveurs Webs doivent tourner sur une seule et même machine au + moyen de serveurs virtuels par nom + ou par IP.

+ +

Fonctionnement de plusieurs serveurs + virtuels par nom sur une seule adresse IP.
Serveurs virtuels par nom sur plus + d'une seule adresse IP.
Servir le même contenu sur des + adresses IP différentes (telle qu'une adresse interne et une + externe).
Servir différents sites sur différents + ports.
Hébergement virtuel basé sur IP
Hébergements virtuels mixtes basés sur + les ports et sur les IP
Hébergements virtuels mixtes basé sur + les noms et sur IP
Utilisation simultanée de + Virtual_host et de mod_proxy
Utilisation de serveurs virtuels + _default_
Migration d'un serveur virtuel + par nom en un serveur virtuel par IP
Utilisation de la directive + ServerPath

Fonctionnement de plusieurs serveurs + virtuels par nom sur une seule adresse IP.

+ +

Votre serveur ne dispose que d'une seule adresse IP, et de + nombreux alias (CNAMES) pointent vers cette adresse dans le DNS. + Pour l'exemple, www.example1.com et + www.example2.org doivent tourner sur cette machine.

+ +

Note :

La configuration de serveurs virtuels + sous Apache ne provoque pas leur apparition magique dans la + configuration du DNS. Il faut que leurs noms soient + définis dans le DNS, et qu'ils y soient résolus sur l'adresse IP + du serveur, faute de quoi personne ne pourra visiter votre site Web. + Il est possible d'ajouter des entrées dans le fichier + hosts pour tests locaux, mais qui ne fonctionneront + que sur la machine possédant ces entrées.

+ +

Configuration du serveur

+ + + # Apache doit écouter sur le port 80 + Listen 80 + + # Toutes les adresses IP doivent répondre aux requêtes sur les + # serveurs virtuels + NameVirtualHost *:80 + + <VirtualHost *:80> + + DocumentRoot /www/example1 + ServerName www.example1.com + + # Autres directives ici + + + </VirtualHost> + + <VirtualHost *:80> + + DocumentRoot /www/example2 + ServerName www.example2.org + + # Autres directives ici + + + </VirtualHost> +

+ +

Les astérisques correspondent à toutes les adresses, si bien que + le serveur principal ne répondra jamais à aucune requête. Comme + www.example1.com se trouve en premier dans le fichier + de configuration, il a la plus grande priorité et peut être vu + comme serveur par défaut ou primaire ; + ce qui signifie que toute requête reçue ne correspondant pas à une + des directives ServerName sera servie par ce premier + VirtualHost.

+ +

Note :

+ +

Si vous le souhaitez, vous pouvez remplacer * + par l'adresse IP du système. Dans ce cas, l'argument de + VirtualHost doit correspondre à + l'argument de NameVirtualHost :

+ +

+ NameVirtualHost 172.20.30.40 + + <VirtualHost 172.20.30.40> + # etc ... +

+ +

En général, il est commode d'utiliser * sur + les systèmes dont l'adresse IP n'est pas constante - par + exemple, pour des serveurs dont l'adresse IP est attribuée + dynamiquement par le FAI, et où le DNS est géré au moyen + d'un DNS dynamique quelconque. Comme * signifie + n'importe quelle adresse, cette configuration + fonctionne sans devoir être modifiée quand l'adresse IP du + système est modifiée.

+ +

La configuration ci-dessus est en pratique utilisée dans la + plupart des cas pour les serveurs virtuels par nom. En fait, le + seul cas où cette configuration ne fonctionne pas est lorsque + différents contenus doivent être servis en fonction de l'adresse IP + et du port contactés par le client.

+ +

Serveurs virtuels par nom sur plus + d'une seule adresse IP.

+ +

Note :

Toutes les techniques présentées ici + peuvent être étendues à un plus grand nombre d'adresses IP.

+ +

Le serveur a deux adresses IP. Sur l'une + (172.20.30.40), le serveur "principal" + server.domain.com doit répondre, et sur l'autre + (172.20.30.50), deux serveurs virtuels (ou plus) + répondront.

+ +

Configuration du serveur

+ + + Listen 80 + + # Serveur "principal" sur 172.20.30.40 + ServerName server.domain.com + DocumentRoot /www/mainserver + + # l'autre adresse + NameVirtualHost 172.20.30.50 + + <VirtualHost 172.20.30.50> + + DocumentRoot /www/example1 + ServerName www.example1.com + + # D'autres directives ici ... + + + </VirtualHost> + + <VirtualHost 172.20.30.50> + + DocumentRoot /www/example2 + ServerName www.example2.org + + # D'autres directives ici ... + + + </VirtualHost> +

+ +

Toute requête arrivant sur une autre adresse que + 172.20.30.50 sera servie par le serveur principal. + Les requêtes vers 172.20.30.50 avec un nom de serveur + inconnu, ou sans en-tête Host:, seront servies par + www.example1.com.

+ +

Servir le même contenu sur des + adresses IP différentes (telle qu'une adresse interne et une + externe).

+ +

La machine serveur dispose de deux adresses IP + (192.168.1.1 et 172.20.30.40). Cette + machine est placée à la fois sur le réseau interne (l'Intranet) + et le réseau externe (Internet). Sur Internet, le nom + server.example.com pointe vers l'adresse externe + (172.20.30.40), mais sur le réseau interne, ce même + nom pointe vers l'adresse interne (192.168.1.1).

+ +

Le serveur peut être configuré pour répondre de la même manière + aux requêtes internes et externes, au moyen d'une seule section + VirtualHost.

+ +

Configuration du serveur

+ + + NameVirtualHost 192.168.1.1 + NameVirtualHost 172.20.30.40 + + <VirtualHost 192.168.1.1 172.20.30.40> + + DocumentRoot /www/server1 + ServerName server.example.com + ServerAlias server + + </VirtualHost> +

+ +

Ainsi, les requêtes en provenance de chacun des deux réseaux + seront servies par le même VirtualHost.

+ +

Note :

Sur le réseau interne, il est possible + d'utiliser le nom raccourci server au lieu du nom + complet server.example.com.

+ +

Notez également que dans l'exemple précédent, vous pouvez + remplacer la liste des adresses IP par des * afin + que le serveur réponde de la même manière sur toutes ses + adresses.

+ +

Servir différents sites sur différents + ports.

+ +

Vous disposez de plusieurs domaines pointant sur la même adresse + IP et vous voulez également servir de multiples ports. Vous y + parviendrez en définissant les ports dans la directive + "NameVirtualHost". Si vous tentez d'utiliser <VirtualHost + name:port> sans directive NameVirtualHost name:port, ou tentez + d'utiliser la directive Listen, votre configuration ne fonctionnera + pas.

+ +

Configuration du serveur

+ + + Listen 80 + Listen 8080 + + NameVirtualHost 172.20.30.40:80 + NameVirtualHost 172.20.30.40:8080 + + <VirtualHost 172.20.30.40:80> + + ServerName www.example1.com + DocumentRoot /www/domain-80 + + </VirtualHost> + + <VirtualHost 172.20.30.40:8080> + + ServerName www.example1.com + DocumentRoot /www/domain-8080 + + </VirtualHost> + + <VirtualHost 172.20.30.40:80> + + ServerName www.example2.org + DocumentRoot /www/otherdomain-80 + + </VirtualHost> + + <VirtualHost 172.20.30.40:8080> + + ServerName www.example2.org + DocumentRoot /www/otherdomain-8080 + + </VirtualHost> +

+ +

Hébergement virtuel basé sur IP

+ +

Le serveur dispose de deux adresses IP (172.20.30.40 + et 172.20.30.50) correspondant respectivement aux noms + www.example1.com et www.example2.org.

+ +

Configuration du serveur

+ + + Listen 80 + + <VirtualHost 172.20.30.40> + + DocumentRoot /www/example1 + ServerName www.example1.com + + </VirtualHost> + + <VirtualHost 172.20.30.50> + + DocumentRoot /www/example2 + ServerName www.example2.org + + </VirtualHost> +

+ +

Les requêtes provenant d'adresses non spécifiées dans l'une des + directives <VirtualHost> (comme pour + localhost par exemple) seront dirigées vers le serveur + principal, s'il en existe un.

+ +

Hébergements virtuels mixtes basés sur + les ports et sur les IP

+ +

Le serveur dispose de deux adresses IP (172.20.30.40 + et 172.20.30.50) correspondant respectivement aux noms + www.example1.com et www.example2.org. + Pour chacun d'eux, nous voulons un hébergement sur les ports 80 + et 8080.

+ +

Configuration du serveur

+ + + Listen 172.20.30.40:80 + Listen 172.20.30.40:8080 + Listen 172.20.30.50:80 + Listen 172.20.30.50:8080 + + <VirtualHost 172.20.30.40:80> + + DocumentRoot /www/example1-80 + ServerName www.example1.com + + </VirtualHost> + + <VirtualHost 172.20.30.40:8080> + + DocumentRoot /www/example1-8080 + ServerName www.example1.com + + </VirtualHost> + + <VirtualHost 172.20.30.50:80> + + DocumentRoot /www/example2-80 + ServerName www.example1.org + + </VirtualHost> + + <VirtualHost 172.20.30.50:8080> + + DocumentRoot /www/example2-8080 + ServerName www.example2.org + + </VirtualHost> +

+ +

Hébergements virtuels mixtes basé sur + les noms et sur IP

+ +

Pour certaines adresses, des serveurs virtuels seront définis + par nom, et pour d'autres, ils seront définis par IP.

+ +

Configuration du serveur

+ + + Listen 80 + + NameVirtualHost 172.20.30.40 + + <VirtualHost 172.20.30.40> + + DocumentRoot /www/example1 + ServerName www.example1.com + + </VirtualHost> + + <VirtualHost 172.20.30.40> + + DocumentRoot /www/example2 + ServerName www.example2.org + + </VirtualHost> + + <VirtualHost 172.20.30.40> + + DocumentRoot /www/example3 + ServerName www.example3.net + + </VirtualHost> + + # "par-IP" + <VirtualHost 172.20.30.50> + + DocumentRoot /www/example4 + ServerName www.example4.edu + + </VirtualHost> + + <VirtualHost 172.20.30.60> + + DocumentRoot /www/example5 + ServerName www.example5.gov + + </VirtualHost> +

+ +

Utilisation simultanée de + `Virtual_host` et de mod_proxy

+ +

L'exemple suivant montre comment une machine peut mandater + un serveur virtuel fonctionnant sur le serveur d'une autre machine. + Dans cet exemple, un serveur virtuel de même nom est configuré sur + une machine à l'adresse 192.168.111.2. La directive + ProxyPreserveHost On est + employée pour permette au nom de domaine d'être préservé lors du + transfert, au cas où plusieurs noms de domaines cohabitent sur + une même machine.

+ +

+ <VirtualHost *:*> + ProxyPreserveHost On + ProxyPass / http://192.168.111.2 + ProxyPassReverse / http://192.168.111.2/ + ServerName hostname.example.com + </VirtualHost> +

+ +

Utilisation de serveurs virtuels + `_default_`

+ +

Serveurs virtuels + `_default_` pour tous les ports

+ +

Exemple de capture de toutes les requêtes émanant + d'adresses IP ou de ports non connus, c'est-à-dire, d'un + couple adresse/port non traité par aucun autre serveur virtuel.

+ +

Configuration du serveur

+ + + <VirtualHost _default_:*> + + DocumentRoot /www/default + + </VirtualHost> +

+ +

L'utilisation d'un tel serveur virtuel avec un joker pour le + port empêche de manière efficace qu'une requête n'atteigne le + serveur principal.

+ +

Un serveur virtuel par défaut ne servira jamais une requête + qui est envoyée vers un couple adresse/port utilisée par un + serveur virtuel par nom. Si la requête contient un en-tête + Host: inconnu, ou si celui-ci est absent, elle + sera toujours servie par le serveur virtuel primaire par nom + (celui correspondant à ce couple adresse/port trouvé en premier + dans le fichier de configuration).

+ +

Vous pouvez utiliser une directive + AliasMatch ou + RewriteRule afin de + réécrire une requête pour une unique page d'information (ou pour + un script).

+ + +

Serveurs virtuels + `_default_` pour des ports différents

+ +

La configuration est similaire à l'exemple précédent, mais + le serveur écoute sur plusieurs ports et un second serveur virtuel + _default_ pour le port 80 est ajouté.

+ +

Configuration du serveur

+ + + <VirtualHost _default_:80> + + DocumentRoot /www/default80 + # ... + + </VirtualHost> + + <VirtualHost _default_:*> + + DocumentRoot /www/default + # ... + + </VirtualHost> +

+ +

Le serveur virtuel par défaut défini pour le port 80 (il doit + impérativement être placé avant un autre serveur virtuel par + défaut traitant tous les ports grâce au joker *) capture toutes + les requêtes envoyées sur une adresse IP non spécifiée. Le + serveur principal n'est jamais utilisé pour servir une requête.

+ + +

Serveurs virtuels + `_default_` pour un seul port

+ +

Nous voulons créer un serveur virtuel par défaut seulement + pour le port 80.

+ +

Configuration du serveur

+ + + <VirtualHost _default_:80> + DocumentRoot /www/default + ... + </VirtualHost> +

+ +

Une requête vers une adresse non spécifiée sur le port 80 + sera servie par le serveur virtuel par défaut, et toute autre + requête vers une adresse et un port non spécifiés sera servie + par le serveur principal.

+ + +

Migration d'un serveur virtuel + par nom en un serveur virtuel par IP

+ +

Le serveur virtuel par nom avec le nom de domaine + www.example2.org (de notre exemple + par nom) devrait obtenir sa propre adresse IP. Pendant la + phase de migration, il est possible d'éviter les problèmes avec + les noms de serveurs et autres serveurs mandataires qui mémorisent + les vielles adresses IP pour les serveurs virtuels par nom.
+ La solution est simple, car il suffit d'ajouter la nouvelle + adresse IP (172.20.30.50) dans la directive + VirtualHost.

+ +

Configuration du serveur

+ + + Listen 80 + ServerName www.example1.com + DocumentRoot /www/example1 + + NameVirtualHost 172.20.30.40 + + <VirtualHost 172.20.30.40 172.20.30.50> + + DocumentRoot /www/example2 + ServerName www.example2.org + # ... + + </VirtualHost> + + <VirtualHost 172.20.30.40> + + DocumentRoot /www/example3 + ServerName www.example3.net + ServerAlias *.example3.net + # ... + + </VirtualHost> +

+ +

Le serveur virtuel peut maintenant être joint par la nouvelle + adresse (comme un serveur virtuel par IP) et par l'ancienne + adresse (comme un serveur virtuel par nom).

+ +

Utilisation de la directive + `ServerPath`

+ +

Dans le cas où vous disposez de deux serveurs virtuels par nom, + le client doit transmettre un en-tête Host: correct + pour déterminer le serveur concerné. Les vieux clients HTTP/1.0 + n'envoient pas un tel en-tête et Apache n'a aucun indice pour + connaître le serveur virtuel devant être joint (il sert la + requête à partir d'un serveur virtuel primaire). Dans un soucis + de préserver la compatibilité descendante, il suffit de créer + un serveur virtuel primaire chargé de retourner une page contenant + des liens dont les URLs auront un préfixe identifiant les serveurs + virtuels par nom.

+ +

Configuration du serveur

+ + + NameVirtualHost 172.20.30.40 + + <VirtualHost 172.20.30.40> + + # Serveur virtuel primaire + DocumentRoot /www/subdomain + RewriteEngine On + RewriteRule ^/.* /www/subdomain/index.html + # ... + + </VirtualHost> + + <VirtualHost 172.20.30.40> + DocumentRoot /www/subdomain/sub1 + + ServerName www.sub1.domain.tld + ServerPath /sub1/ + RewriteEngine On + RewriteRule ^(/sub1/.*) /www/subdomain$1 + # ... + + </VirtualHost> + + <VirtualHost 172.20.30.40> + + DocumentRoot /www/subdomain/sub2 + ServerName www.sub2.domain.tld + ServerPath /sub2/ + RewriteEngine On + RewriteRule ^(/sub2/.*) /www/subdomain$1 + # ... + + </VirtualHost> +

+ +

À cause de la directive + ServerPath, une requête sur + une URL http://www.sub1.domain.tld/sub1/ est + toujours servie par le serveur sub1-vhost.
+ Une requête sur une URL http://www.sub1.domain.tld/ n'est + servie par le serveur sub1-vhost que si le client envoie un en-tête + Host: correct. Si aucun en-tête Host: + n'est transmis, le serveur primaire sera utilisé.
+ Notez qu'il y a une singularité : une requête sur + http://www.sub2.domain.tld/sub1/ est également servie + par le serveur sub1-vhost si le client n'envoie pas d'en-tête + Host:.
+ Les directives RewriteRule + sont employées pour s'assurer que le client qui envoie un en-tête + Host: correct puisse utiliser d'autres variantes d'URLs, + c'est-à-dire avec ou sans préfixe d'URL.

+ +

Langues Disponibles: en | + fr | + ja | + ko

+ \ No newline at end of file