Mechanismus zur Protokollaktualisierung

Das Upgrade-Header-Feld wird von Clients verwendet, um den Server einzuladen, auf eines der gelisteten Protokolle umzuschalten, in absteigender Prioritätsreihenfolge.

Da Upgrade ein Hop-by-Hop-Header ist, muss es auch im Connection-Header-Feld aufgelistet werden. Das bedeutet, dass eine typische Anfrage, die Upgrade umfasst, in etwa so aussehen würde:

GET /index.html HTTP/1.1
Host: www.example.com
Connection: upgrade
Upgrade: example/1, foo/2

Je nach angefordertem Protokoll können weitere Header erforderlich sein; zum Beispiel erlauben WebSocket-Upgrades zusätzliche Header, um Details über die WebSocket-Verbindung zu konfigurieren sowie um ein gewisses Maß an Sicherheit bei der Öffnung der Verbindung zu bieten. Siehe Upgraden zu einer WebSocket-Verbindung für weitere Einzelheiten.

Wenn der Server sich entscheidet, die Verbindung zu upgraden, sendet er einen 101 Switching Protocols-Antwortstatus mit einem Upgrade-Header zurück, der die Protokolle angibt, auf die umgeschaltet wird. Wenn er die Verbindung nicht upgraden kann (oder nicht will), ignoriert er den Upgrade-Header und sendet eine normale Antwort zurück (zum Beispiel ein 200 OK).

Unmittelbar nach dem Senden des 101-Statuscodes kann der Server beginnen, das neue Protokoll zu sprechen, und dabei alle zusätzlichen protokollspezifischen Handshakes durchführen, die erforderlich sind. Effektiv wird die Verbindung zu einem Zwei-Wege-Pipe, sobald die aktualisierte Antwort abgeschlossen ist, und die Anfrage, die das Upgrade initiiert hat, kann über das neue Protokoll abgeschlossen werden.

Hier betrachten wir die häufigsten Anwendungsfälle für den Upgrade-Header.

Bei weitem der häufigste Anwendungsfall für das Upgraden einer HTTP-Verbindung ist die Verwendung von WebSockets, die immer durch das Upgraden einer HTTP- oder HTTPS-Verbindung implementiert werden. Beachten Sie, dass, wenn Sie eine neue Verbindung mit der WebSocket-API öffnen oder eine beliebige Bibliothek verwenden, die WebSockets unterstützt, dies meist oder vollständig für Sie erledigt wird. Zum Beispiel ist das Öffnen einer WebSocket-Verbindung eine einzelne Methode:

webSocket = new WebSocket("ws://destination.server.ext", "optionalProtocol");

Der WebSocket()-Konstruktor erledigt die gesamte Arbeit, eine anfängliche HTTP/1.1-Verbindung zu erstellen und dann den Handshake- und Upgrade-Prozess für Sie zu handhaben.

Wenn Sie eine WebSocket-Verbindung von Grund auf erstellen müssen, müssen Sie den Handshake-Prozess selbst handhaben. Nachdem Sie die anfängliche HTTP/1.1-Sitzung erstellt haben, müssen Sie das Upgrade anfordern, indem Sie einem Standardanfrage die Upgrade- und Connection-Header hinzufügen, wie folgt:

Connection: Upgrade
Upgrade: websocket

Die folgenden Header sind im WebSocket-Upgrade-Prozess involviert. Abgesehen von den Upgrade- und Connection-Headern sind die restlichen im Allgemeinen optional oder werden vom Browser und Server für Sie gehandhabt, wenn sie miteinander kommunizieren.

Sec-WebSocket-Extensions

Gibt an, dass der Server gebeten wird, eine oder mehrere WebSocket-Erweiterungen auf Protokollebene zu verwenden. Mehr als einen Sec-WebSocket-Extension-Header in einer Anfrage zu verwenden, ist erlaubt; das Ergebnis ist dasselbe, als wenn Sie alle aufgeführten Erweiterungen in einem solchen Header enthalten würden.

Sec-WebSocket-Extensions: extensions

extensions

Eine durch Kommas getrennte Liste von Erweiterungen, die angefordert werden sollen (oder deren Unterstützung zugesagt wird). Diese sollten aus dem IANA WebSocket Extension Name Registry ausgewählt werden. Erweiterungen, die Parameter verwenden, tun dies mittels Semikolon-Abtrennung.

Beispielsweise:

Sec-WebSocket-Extensions: superspeed, colormode; depth=16

Sec-WebSocket-Key

Stellt dem Server Informationen zur Verfügung, die benötigt werden, um zu bestätigen, dass der Client berechtigt ist, ein Upgrade auf WebSocket zu beantragen. Dieser Header kann verwendet werden, wenn unsichere (HTTP) Clients ein Upgrade wünschen, um einen gewissen Schutz gegen Missbrauch zu bieten. Der Wert des Schlüssels wird unter Verwendung eines im WebSocket-Spezifikation definierten Algorithmus berechnet, so dass dies keine Sicherheit bietet. Es hilft vielmehr dabei, zu verhindern, dass Nicht-WebSocket-Clients versehentlich oder durch Missbrauch eine WebSocket-Verbindung anfordern. Im Wesentlichen bestätigt dann dieser Schlüssel, dass "Ja, ich möchte wirklich eine WebSocket-Verbindung eröffnen."

Dieser Header wird automatisch von Clients hinzugefügt, die ihn verwenden möchten; er kann nicht mit den Methoden fetch() oder XMLHttpRequest.setRequestHeader() hinzugefügt werden.

Sec-WebSocket-Key: key

key

Der Schlüssel für dieses Upgrade-Anforderung. Der Client fügt diesen hinzu, wenn er es wünscht, und der Server wird in der Antwort einen eigenen Schlüssel enthalten, den der Client validiert, bevor er Ihnen die Upgrade-Antwort liefert.

Der Sec-WebSocket-Accept-Header der Serverantwort enthält einen Wert, der auf dem angegebenen key-Wert berechnet wird.

Sec-WebSocket-Protocol

Der Sec-WebSocket-Protocol-Header gibt an, welche WebSocket-Protokolle Sie verwenden möchten, in der Reihenfolge der Präferenz. Das erste, das vom Server unterstützt wird, wird ausgewählt und vom Server in einem Sec-WebSocket-Protocol-Header in der Antwort zurückgegeben. Sie können dies auch mehr als einmal im Header verwenden; das Ergebnis ist dasselbe, als wenn Sie eine durch Kommas getrennte Liste von Subprotokoll-IDs in einem einzelnen Header verwendet hätten.

Sec-WebSocket-Protocol: subprotocols

subprotocols

Eine durch Kommas getrennte Liste von Subprotokollnamen, in der Reihenfolge der Präferenz. Die Subprotokolle können aus dem IANA WebSocket Subprotocol Name Registry ausgewählt oder eine benutzerdefinierte Bezeichnung sein, die vom Client und Server gemeinsam verstanden wird.

Sec-WebSocket-Version

Anfrage-Header

Gibt an, welche WebSocket-Protokollversion der Client verwenden möchte, damit der Server bestätigen kann, ob diese Version unterstützt wird.

Sec-WebSocket-Version: version

version

Die WebSocket-Protokollversion, die der Client verwenden möchte, wenn er mit dem Server kommuniziert. Diese Zahl sollte die neueste mögliche Version sein, die im IANA WebSocket Version Number Registry gelistet ist. Die neueste finale Version des WebSocket-Protokolls ist Version 13.

Antwort-Header

Wenn der Server nicht mit der angegebenen Version des WebSocket-Protokolls kommunizieren kann, antwortet er mit einem Fehler (wie 426 Upgrade Required), der in seinen Headern ein Sec-WebSocket-Version-Header mit einer durch Kommas getrennten Liste der unterstützten Protokollversionen enthält. Wenn der Server die angeforderte Protokollversion unterstützt, wird in der Antwort kein Sec-WebSocket-Version-Header enthalten sein.

Sec-WebSocket-Version: supportedVersions

supportedVersions

Eine durch Kommas getrennte Liste der WebSocket-Protokollversionen, die vom Server unterstützt werden.

Die Antwort vom Server kann diese enthalten.

Sec-WebSocket-Accept

Wird in der Antwortnachricht vom Server während des Eröffnungs-Handshakes-Prozesses enthalten, wenn der Server bereit ist, eine WebSocket-Verbindung zu initiieren. Es wird nicht mehr als einmal in den Antwortheadern erscheinen.

Sec-WebSocket-Accept: hash

hash

Wenn ein Sec-WebSocket-Key-Header bereitgestellt wurde, wird der Wert dieses Headers berechnet, indem Sie den Wert des Schlüssels nehmen, den String "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" daran anfügen, den SHA-1-Hash dieses angefügten Strings nehmen, was zu einem 20-Byte-Wert führt. Dieser Wert wird dann base64 codiert, um den Wert dieser Eigenschaft zu erhalten.

• WebSocket API
• Evolution von HTTP
• Glossarbegriffe:
  • HTTP
  • HTTP/2
  • QUIC