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 .
vhostnur 3 nahe Vorkommenvirtual hostmit einer Bedeutung, die nicht in der Nähe Ihrer Phrase liegt, und 12 fürdefaulthauptsächlich über Hafen,by the book) konfiguriert ist?defaultWort durch Suche gefunden,Otherwise, the authority component is assigned the default name configured for the servervirtual hostdie ich bei meiner Suche in tools.ietf.org/html/rfc7230 gefunden habe, sind inAppendix A. HTTP Version History. Es sieht so aus, als hätte Ihre Suche eine andere gefunden.Ich würde immer empfehlen, zur maßgeblichen Quelle zu gehen, wenn Sie versuchen, die Bedeutung und den Zweck von HTTP-Headern zu verstehen.
https://tools.ietf.org/html/rfc7230#section-5.4
quelle