Zusammenfassung

  • HTTP/1.0 konnte über TCP einen Pfad anfragen, doch die Zieladresse bewahrte den zuvor gewählten DNS-Namen nicht für den Webserver auf.
  • HTTP/1.1 verlangte Host, damit ein Pfad zum richtigen Namensraum gehörte und mehrere Sites eine IP-Adresse teilen konnten.
  • Weil eine absolute Request-URI ebenfalls Authority enthält, legten Standards Vorrang, Proxy-Normalisierung und Ablehnung fehlender, mehrfacher oder ungültiger Werte fest.

Eine Adresse und ein Schrägstrich

RFC 1945 dokumentierte den verbreiteten HTTP/1.0-Gebrauch. Der Client löste einen Namen auf, öffnete TCP und sandte oft nur einen Pfad. Bei einer Site pro Adresse schien GET / eindeutig: Die Verbindung wählte implizit die einzige Wurzel.

Mehrere Namen konnten jedoch dieselbe IP erreichen. Die DNS-Anfrage reiste nicht mit dem TCP-Stream. Der Server sah Adresse und Port, nicht den ursprünglichen Namen. Auf einem geteilten Endpoint konnte derselbe Pfad zu mehreren Sites gehören.

Host ergänzte das Ziel

RFC 2068 verpflichtete 1997 Host in HTTP/1.1. Beim direkten Origin enthält die Request-Line meist Pfad und Query, Host die Netzlokation. Erst beides bestimmt die Ressource.

Fehlendes Host musste 400 auslösen. Die Spezifikation nannte Mehrfachhosting auf einer IP und die Rückgewinnung nur zur Namenstrennung belegter Adressen als Zweck.

Host ist eine Absichtserklärung, kein Eigentumsnachweis. Der Origin muss die Authority gegen seine Konfiguration prüfen.

Zwei Authorities brauchen Vorrang

Origin-form trägt nur den Pfad. Absolute-form für Proxies enthält bereits Scheme, Host und Pfad. Widersprechen sich absolute URI und Host, besitzt die Nachricht zwei Ziele.

RFC 2068 priorisierte die absolute URI. RFC 7230 verlangte später, dass der Proxy Host daraus neu setzt. Ein Intermediär darf den Konflikt nicht weiterreichen.

Ohne Host, mit mehreren Host-Zeilen oder ungültigem Wert folgt 400. Die erste oder letzte Kopie willkürlich zu wählen ließe Proxy, Cache und Origin verschiedene Sites auswählen.

Das effektive Ziel wird konstruiert

RFC 7230 nennt das Ergebnis effective request URI. Serverkonfiguration, Verbindungskontext, Target-Form und Host fließen in definierter Ordnung ein. Ein Pfad erhält seine Bedeutung erst in einer Authority.

User Agent erklärt, Proxy normalisiert, Origin validiert und wählt den Virtual Host. Cache und Redirect müssen dieselbe Authority verwenden. Der RFC warnt vor ungeprüftem Host für internes Routing oder Shared-Cache-Schlüssel.

Die Gefahr entsteht gerade aus seiner Routingwirkung: Der Anfordernde liefert ein Feld, das den Anwendungsadressaten auswählt.

Die eine Authority überdauerte das Format

RFC 9112 behält einen einzigen gültigen Host für HTTP/1.1 bei. Mehrdeutigkeit wird nicht erraten.

HTTP/2 verwendet :authority. Nach RFC 9113 muss ein Übersetzer daraus Host erzeugen und einen vorhandenen Wert ersetzen, sofern er nicht zugleich das Target ändert. Der Protokollwechsel bewahrt eine Authority, keine Konkurrenz.

Host trennte Site und IP. Dadurch entstand an jedem Hop die Pflicht, den Namen eindeutig und konsistent zu halten.

Quellen und Grenzen

Der geschlossene Satz ist RFC 1945, RFC 2068, RFC 7230, RFC 9112 und RFC 9113. Er belegt Regeln und Motivation, nicht heutige Site-Zahlen, eingesparte IPs, Produktdefaults oder Vorfallhäufigkeit. Host authentifiziert weder DNS, TLS noch Sender.