Résumé

  • HTTP/1.0 pouvait envoyer un chemin sur une connexion TCP, mais l’adresse de destination ne conservait pas nécessairement le nom DNS choisi par l’utilisateur.
  • HTTP/1.1 imposa Host pour placer le chemin dans le bon espace de ressources et permettre à plusieurs sites de partager une adresse.
  • Comme l’autorité peut aussi figurer dans une URI absolue, les normes fixèrent priorité, réécriture par les mandataires et rejet des valeurs absentes, multiples ou invalides.

Une adresse n’était plus un site

La RFC 1945 décrit l’usage courant de HTTP/1.0. Le client résout un nom, ouvre TCP vers une adresse, puis demande souvent un simple chemin. Tant que l’adresse ne sert qu’un site, GET / paraît complet : la connexion choisit implicitement l’unique racine.

Le partage détruit cette supposition. DNS peut faire converger plusieurs noms vers la même adresse, mais la requête DNS originale n’est pas remise au serveur Web avec le flux TCP. L’adresse et le port indiquent où livrer les octets ; ils ne restituent pas le nom que l’utilisateur voulait atteindre.

Host compléta la cible

La RFC 2068, publiée en janvier 1997, exigea Host dans toute requête HTTP/1.1 sur Internet. En connexion directe, la ligne de requête garde normalement chemin et query ; Host transporte la localisation réseau. La ressource exacte résulte des deux.

L’absence devait produire 400. L’annexe qualifia cette obligation de changement majeur, destiné à accueillir plusieurs sites sur une IP et à libérer les adresses utilisées uniquement pour distinguer des noms Web.

Host ne prouve ni propriété ni authenticité. Il déclare l’autorité voulue par le client. Le serveur doit encore vérifier qu’il sert ce nom avant de router la requête.

Deux copies exigeaient une hiérarchie

Un client parlant directement à l’origine emploie généralement la forme origin, donc un chemin. Un proxy peut recevoir une forme absolue contenant déjà schéma, hôte et chemin. Si cette URI nomme A et Host nomme B, il existe deux décisions possibles.

RFC 2068 donna la priorité à l’URI absolue. La RFC 7230 demanda ensuite au proxy de remplacer Host par l’autorité de cette URI. La transformation ne doit pas propager une contradiction.

La même recherche d’unicité justifie les refus : aucun Host, plusieurs Host ou une valeur invalide entraînent 400. Choisir arbitrairement la première ou la dernière valeur autoriserait cache, proxy et origine à interpréter différemment une même requête.

L’URI effective est un résultat

RFC 7230 parle d’URI effective de la requête. Sa reconstruction utilise la configuration locale, le contexte de connexion, la forme de la cible et Host. Le chemin n’est donc pas seul ; l’autorité détermine le catalogue où ce chemin prend sens.

Chaque acteur détient une part de contrôle. Le navigateur déclare la cible. Le mandataire normalise. L’origine accepte un nom et sélectionne le site virtuel. Le cache et les redirections doivent employer la même autorité validée. RFC 7230 avertit précisément contre l’usage d’un Host non vérifié pour rediriger vers des serveurs internes ou former une clé de cache partagée.

Le danger vient du pouvoir du champ, non de son caractère accessoire : une donnée envoyée par le demandeur participe directement au choix du destinataire applicatif.

Le nom a survécu au changement de format

La RFC 9112 maintient pour HTTP/1.1 un Host unique et valide. Les demandes ambiguës ne sont pas réparées par intuition.

HTTP/2 déplace l’autorité vers le pseudo-en-tête :authority. Selon la RFC 9113, un intermédiaire qui reconstruit HTTP/1.1 doit en tirer Host et remplacer une éventuelle ancienne valeur, sauf modification parallèle de la cible. La syntaxe change ; l’invariant reste une seule autorité lors de la traduction.

Une ligne obligatoire a donc rompu le lien historique entre une adresse et un site. En retour, elle a imposé à chaque relais de conserver une identité cohérente jusqu’à l’origine.

Sources et limites

Le corpus fermé comprend les RFC 1945, 2068, 7230, 9112 et 9113. Il établit les règles et leur motivation, mais non les nombres actuels de sites, d’adresses économisées, les réglages produits ou la fréquence des attaques. Host n’authentifie ni DNS, ni TLS, ni l’émetteur.