Was ist der http-Host-Header?

Da die TCP-Verbindung bereits beim Senden der HTTP-Anforderung hergestellt wurde, sind IP-Adresse und Port implizit bekannt - eine TCP-Verbindung ist ein IP + -Port. Warum brauchen wir den HostHeader? Wird dies nur für den Fall benötigt, dass mehrere Hosts der in der TCP-Verbindung implizierten IP-Adresse zugeordnet sind?

Der hostHeader teilt dem Webserver mit, welcher virtuelle Host verwendet werden soll (falls eingerichtet). Sie können sogar denselben virtuellen Host mit mehreren Aliasen (= Domänen und Platzhalterdomänen) verwenden. In diesem Fall haben Sie weiterhin die Möglichkeit, diesen Header manuell in Ihrer Webanwendung zu lesen, wenn Sie ein unterschiedliches Verhalten basierend auf verschiedenen angesprochenen Domänen bereitstellen möchten. Dies ist möglich, weil Sie in Ihrem Webserver (und wenn ich mich nicht irre, müssen Sie) einen vhost als Standardhost einrichten . Dieser Standard-vhost wird immer dann verwendet, wenn derhost Header keinem der konfigurierten virtuellen Hosts entspricht.

Das heißt: Sie verstehen es richtig, obwohl die Aussage "mehrere Hosts" etwas irreführend sein kann: Der Host (der adressierte Computer) ist derselbe. Was wirklich in die IP-Adresse aufgelöst wird, sind verschiedene Domainnamen (einschließlich Subdomains), auf die ebenfalls verwiesen wird als Hostnamen (aber keine Hosts!).

Obwohl nicht Teil der Frage, eine lustige Tatsache: Diese Spezifikation führte in den frühen Tagen zu Problemen mit SSL, da der Webserver das Zertifikat liefern muss, das der Domäne entspricht, die der Client angesprochen hat. Um jedoch zu wissen, welches Zertifikat verwendet werden soll, sollte der Webserver den adressierten Hostnamen im Voraus kennen. Da der Client diese Informationen jedoch nur über den verschlüsselten Kanal sendet (dh nachdem das Zertifikat bereits gesendet wurde), musste der Server davon ausgehen, dass Sie den Standardhost durchsucht haben. Das bedeutete eine SSL-gesicherte Domain pro IP-Adresse / Port-Kombination.

Dies wurde mit der Angabe des Servernamens überwunden . Dies beeinträchtigt jedoch erneut die Privatsphäre, da der Servername jetzt wieder im Klartext übertragen wird, sodass jeder Mann in der Mitte sehen würde, welcher Hostname verwendet wird Sie eine Verbindung herstellen .

Obwohl der Webserver den Hostnamen aus der Servernamenanzeige kennt, ist der hostHeader nicht veraltet, da die Informationen zur Servernamenanzeige nur im TLS-Handshake verwendet werden. Bei einer ungesicherten Verbindung gibt es überhaupt keine Servernamenanzeige, sodass der hostHeader weiterhin gültig (und erforderlich) ist.

Eine weitere lustige Tatsache: Die meisten Webserver (wenn nicht alle) lehnen Ihre http-Anfrage ab, wenn sie nicht genau einen hostHeader enthält, auch wenn sie weggelassen werden könnte, da nur der Standard-vhost konfiguriert ist. Das bedeutet, dass die minimal erforderlichen Informationen in einer http- (get-) Anfrage die erste Zeile sind, die METHOD RESOURCEund PROTOCOL VERSIONund zumindest den host-header wie folgt enthält :

GET /someresource.html HTTP/1.1
Host: www.example.com

In der MDN-Dokumentation zum Host-Header wird dies tatsächlich so formuliert:

In allen HTTP / 1.1-Anforderungsnachrichten muss ein Host-Header-Feld gesendet werden. Ein 400-Statuscode (Bad Request) wird an jede HTTP / 1.1-Anforderungsnachricht gesendet, der ein Host-Header-Feld fehlt oder mehr als ein Feld enthält.

Wie von Darrel Miller erwähnt, finden Sie die vollständigen technischen Daten in RFC7230 .

Ich würde immer empfehlen, zur maßgeblichen Quelle zu gehen, wenn Sie versuchen, die Bedeutung und den Zweck von HTTP-Headern zu verstehen.

Das Headerfeld "Host" in einer Anforderung enthält die Host- und Portinformationen
aus dem Ziel-URI, sodass der Ursprungsserver
zwischen Ressourcen unterscheiden kann, während Anforderungen für mehrere
Hostnamen an einer einzelnen IP-Adresse bearbeitet werden.

https://tools.ietf.org/html/rfc7230#section-5.4