Vision du web. La réponse collaborative.

Gagner des Bitcoins.

Gagner des Bitcoins !
Le HackerSpace Vision du web.
La réponse collaborative.
Le glider des Hackers.
Un symbole de rassemblement.
QWERTY.
Du clavier au terminal.
GNU / Linux Debian.
La distribution universelle.
GNU / Linux Ubuntu.
Linux pour les êtres humains.
GNU / Linux Arch.
Un Linux léger et flexible.
Nom de code Linux.
Documentaire FR.

Le montant des donations pour Vision du web est de 0.058724145696252 Monero.

Soutenir Vision du Web dans son partage de logiciels et de ressources libres

Ce mineur crée de la monnaie numérique Monero pour soutenir Vision du web.
Merci de désactiver votre bloqueur de publicité.
Aucune publicité ne sera affichée.
Le mineur utilise les ressources de votre machine pour créer gratuitement de la monnaie numérique.

Vous n´êtes pas identifié(e).

Nous sommes le vendredi 20 juillet 2018. Il est .

Nous avons 659 invités et aucun membre en ligne

 
HackerSpace !
× Gestion d'un serveur Apache.

VirtualHost et ordre de lecture de Apache

  • VisionDuWeb
  • Portrait de VisionDuWeb Auteur du sujet
  • Hors Ligne
  • Modérateur
  • Modérateur
  • Animateur.
Plus d'informations
il y a 3 ans 1 mois - il y a 3 ans 1 mois #703 par VisionDuWeb
VisionDuWeb a créé le sujet : VirtualHost et ordre de lecture de Apache
À la réception d'une requête, le serveur doitdé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 IPSi 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.
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.

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


Voir aussi
Serveurs Virtuels par-Nom
(Un ou plusieurs sites Web par adresse IP)

Serveurs Virtuels par-IP
(Une adresse IP pour chaque site Web)

Vision du web. La réponse collaborative.
Dernière édition: il y a 3 ans 1 mois par VisionDuWeb.

Connexion ou Créer un compte pour participer à la conversation.

REMARQUE ! Ce site utilise des cookies et autres technologies similaires.

Si vous ne changez pas les paramètres de votre navigateur, vous êtes d'accord. En savoir plus

J'ai compris

En poursuivant votre navigation sur ce site, vous acceptez l’utilisation de Cookies pour vous proposer un accès membre personnalisé et réaliser des statistiques de visites.

Vision du web sur votre réseau social

La plus parfaite éducation consiste à habituer le disciple à se passer de maître.
[Robert Sabatier]

Votre hébergement internet avec LWS.