HTTP-Nachrichten

HTTP-Anfragen sind Nachrichten, die vom Client gesendet werden, um eine Aktion auf dem Server zu initiieren. Ihre Anfragelinie enthält drei Elemente:

1. Eine HTTP-Methode, ein Verb (wie GET, PUT oder POST) oder ein Substantiv (wie HEAD oder OPTIONS), das die auszuführende Aktion beschreibt. Zum Beispiel gibt GET an, dass eine Ressource abgerufen werden soll, oder POST bedeutet, dass Daten an den Server gesendet werden (zur Erstellung oder Änderung einer Ressource oder zur Generierung eines temporären Dokuments, das zurückgesendet wird).

2. Das Ziel der Anfrage, in der Regel eine URL, oder der absolute Pfad des Protokolls, Ports und der Domain wird normalerweise durch den Anfragekontext charakterisiert. Das Format dieses Anfrageziels variiert zwischen verschiedenen HTTP-Methoden. Es kann sein:

   • Ein absoluter Pfad, letztlich gefolgt von einem '?' und einer Abfragezeichenfolge. Dies ist die häufigste Form, bekannt als die Ursprungsform, und wird mit den Methoden GET, POST, HEAD und OPTIONS verwendet.
     • POST / HTTP/1.1
     • GET /background.png HTTP/1.0
     • HEAD /test.html?query=alibaba HTTP/1.1
     • OPTIONS /any-page.html HTTP/1.0
   • Eine vollständige URL, bekannt als die absolute Form, wird hauptsächlich mit GET verwendet, wenn eine Verbindung zu einem Proxy besteht. GET https://developer.mozilla.org/de/docs/Web/HTTP/Messages HTTP/1.1
   • Die Autoritätskomponente einer URL, bestehend aus dem Domainnamen und optional dem Port (eingeleitet durch ein ':'), wird als Autoritätsform bezeichnet. Sie wird nur mit CONNECT verwendet, wenn ein HTTP-Tunnel eingerichtet wird. CONNECT developer.mozilla.org:80 HTTP/1.1
   • Die Sternchenform, ein einfaches Sternchen ('*'), wird mit OPTIONS verwendet und repräsentiert den Server als Ganzes. OPTIONS * HTTP/1.1

3. Die HTTP-Version, die die Struktur der verbleibenden Nachricht definiert und als Indikator für die erwartete zu verwendende Version für die Antwort dient.

HTTP-Header einer Anfrage folgen dem gleichen Grundaufbau eines HTTP-Headers: ein nicht case-sensitiver String gefolgt von einem Doppelpunkt (':') und einem Wert, dessen Struktur vom Header abhängt. Der gesamte Header, einschließlich des Werts, besteht aus einer einzigen Zeile, die ziemlich lang sein kann.

Viele verschiedene Header können in Anfragen erscheinen. Diese können in mehrere Gruppen unterteilt werden:

• Allgemeine Header, wie Via, gelten für die gesamte Nachricht.
• Anfrage-Header, wie User-Agent oder Accept, modifizieren die Anfrage durch eine genauere Spezifikation (wie Accept-Language), durch die Angabe von Kontext (wie Referer) oder durch bedingte Einschränkung (wie If-None-Match).
• Repräsentationsheader wie Content-Type, die das ursprüngliche Format der Nachrichtendaten und jede angewendete Kodierung beschreiben (nur vorhanden, wenn die Nachricht einen Körper hat).

Der letzte Teil einer Anfrage ist der Körper. Nicht alle Anfragen haben einen: Anfragen mit einer GET HTTP-Methode sollten nur zum Anfordern von Daten verwendet werden und keinen Körper enthalten.

Körper können grob in zwei Kategorien unterteilt werden:

• Einzelressourcen-Körper, bestehend aus einer einzigen Datei, definiert durch die zwei Header: Content-Type und Content-Length.
• Mehrfachressourcen-Körper, bestehend aus einem mehrteiligen Körper, der jeweils ein anderes Informationsstück enthält. Dies ist typischerweise mit HTML-Formularen verbunden.

Die Startzeile einer HTTP-Antwort, die Statuszeile genannt wird, enthält folgende Informationen:

1. Die Protokollversion, normalerweise HTTP/1.1, aber es kann auch HTTP/1.0 sein.
2. Ein Statuscode, der den Erfolg oder Misserfolg der Anfrage angibt. Gängige Statuscodes sind 200, 404 oder 302.
3. Ein Status-Text. Eine kurze, rein informative, textuelle Beschreibung des Statuscodes, um einem Menschen zu helfen, die HTTP-Nachricht zu verstehen.

Eine typische Statuszeile sieht so aus: HTTP/1.1 404 Not Found.

HTTP-Header für Antworten folgen der gleichen Struktur wie jeder andere Header: ein nicht case-sensitiver String gefolgt von einem Doppelpunkt (':') und einem Wert, dessen Struktur vom Typ des Headers abhängt. Der gesamte Header, einschließlich seines Werts, präsentiert sich als eine einzelne Zeile.

Viele verschiedene Header können in Antworten erscheinen. Diese können in mehrere Gruppen unterteilt werden:

• Allgemeine Header, wie Via, gelten für die gesamte Nachricht.
• Antwort-Header, wie Vary und Accept-Ranges, geben zusätzliche Informationen über den Server, die nicht in die Statuszeile passen.
• Repräsentationsheader wie Content-Type, die das ursprüngliche Format der Nachrichtendaten und jede angewendete Kodierung beschreiben (nur vorhanden, wenn die Nachricht einen Körper hat).

Der letzte Teil einer Antwort ist der Körper. Nicht alle Antworten haben einen: Antworten mit einem Statuscode, der die Anfrage ausreichend beantwortet, ohne dass Inhalt inkludiert werden muss (wie 201 Created oder 204 No Content), haben in der Regel keinen.

Körper können grob in drei Kategorien unterteilt werden:

• Einzelressourcen-Körper, bestehend aus einer einzelnen Datei bekannter Länge, definiert durch die zwei Header: Content-Type und Content-Length.
• Einzelressourcen-Körper, bestehend aus einer einzelnen Datei unbekannter Länge, kodiert in Chunks mit Transfer-Encoding auf chunked gesetzt.
• Mehrfachressourcen-Körper, bestehend aus einem mehrteiligen Körper, der jeweils unterschiedliche Abschnitte von Informationen enthält. Diese sind relativ selten.

HTTP/1.x-Nachrichten haben einige Nachteile in Bezug auf die Leistung:

• Header, im Gegensatz zu Körpern, sind unkomprimiert.
• Header sind oft sehr ähnlich von einer Nachricht zur nächsten, werden aber dennoch über Verbindungen hinweg wiederholt.
• Obwohl HTTP/1.1 Pipelining hat, wird es in den meisten Browsern nicht standardmäßig aktiviert und erlaubt keine Multiplexierung (d. h., gleichzeitiges Senden von Anfragen). Es müssen mehrere Verbindungen zum gleichen Server geöffnet werden, um Anfragen gleichzeitig zu senden; und warme TCP-Verbindungen sind effizienter als kalte.

HTTP/2 führt einen zusätzlichen Schritt ein: Es teilt HTTP/1.x-Nachrichten in Rahmen, die in einen Stream eingebettet sind. Daten- und Header-Rahmen sind getrennt, was eine Header-Kompression ermöglicht. Mehrere Streams können zusammen kombiniert werden, ein Prozess, der Multiplexing genannt wird, der eine effizientere Nutzung der zugrundeliegenden TCP-Verbindungen ermöglicht.

HTTP-Rahmen sind nun für Webentwickler transparent. Dies ist ein zusätzlicher Schritt in HTTP/2, zwischen HTTP/1.1-Nachrichten und dem darunterliegenden Transportprotokoll. Es sind keine Änderungen in den von Webentwicklern verwendeten APIs erforderlich, um HTTP-Rahmen zu nutzen; wenn sowohl im Browser als auch im Server verfügbar, wird HTTP/2 aktiviert und verwendet.

HTTP-Nachrichten sind der Schlüssel zur Nutzung von HTTP; ihre Struktur ist einfach und sie sind hochgradig erweiterbar. Der HTTP/2-Rahmenmechanismus fügt eine neue Zwischenebene zwischen der HTTP/1.x-Syntax und dem zugrunde liegenden Transportprotokoll hinzu, ohne es grundlegend zu ändern: er baut auf bewährten Mechanismen auf.