Protocol upgrade mechanism

Das Upgrade Header-Feld wird von Clients verwendet, um den Server einzuladen, auf eines der aufgelisteten Protokolle umzuschalten, in absteigender Präferenzreihenfolge.

Da Upgrade ein Hop-by-Hop-Header ist, muss es auch im Connection Header-Feld aufgelistet werden. Dies bedeutet, dass eine typische Anfrage, die ein Upgrade enthält, etwa so aussieht:

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

Abhängig vom angeforderten Protokoll können weitere Header erforderlich sein; zum Beispiel erlauben WebSocket-Upgrades zusätzliche Header, um Details über die WebSocket-Verbindung zu konfigurieren und um ein gewisses Maß an Sicherheit beim Öffnen der Verbindung zu bieten. Weitere Einzelheiten finden Sie unter Upgrade zu einer WebSocket-Verbindung.

Wenn der Server entscheidet, die Verbindung zu upgraden, sendet er einen Rückmeldestatus von 101 Switching Protocols mit einem Upgrade-Header zurück, der das/ die Protokoll(e) angibt, zu dem/denen gewechselt wird. Wenn das Upgrade nicht (oder nicht sofort) durchgeführt wird, ignoriert der Server den Upgrade-Header und sendet eine normale Antwort zurück (zum Beispiel ein 200 OK).

Direkt nach dem Senden des 101-Statuscodes kann der Server beginnen, das neue Protokoll zu sprechen und alle weiteren, prokollspezifischen Handshakes durchzuführen. Effektiv wird die Verbindung zu einem Zwei-Wege-Kanal, 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 Upgrade einer HTTP-Verbindung ist die Verwendung von WebSockets, die immer durch ein Upgrade einer HTTP- oder HTTPS-Verbindung implementiert werden. Beachten Sie, dass, wenn Sie eine neue Verbindung unter Verwendung der WebSocket-API oder einer beliebigen Bibliothek, die WebSockets implementiert, öffnen, das meiste davon für Sie erledigt wird. Zum Beispiel ist das Öffnen einer WebSocket-Verbindung so einfach wie:

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

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

Wenn Sie eine WebSocket-Verbindung von Grund auf erstellen müssen, müssen Sie den Handshaking-Prozess selbst handhaben. Nach dem Erstellen der initialen HTTP/1.1-Sitzung müssen Sie das Upgrade anfordern, indem Sie in einer Standardanfrage die Header Upgrade und Connection hinzufügen, wie folgt:

Connection: Upgrade
Upgrade: websocket

Die folgenden Header sind im WebSocket-Upgrade-Prozess involviert. Abgesehen von den Headern Upgrade und Connection, sind die anderen generell optional oder werden von dem Browser und Server automatisch gehandhabt, wenn sie miteinander kommunizieren.

Sec-WebSocket-Extensions

Spezifiziert eine oder mehrere Protokoll-Level WebSocket-Erweiterungen, die der Server verwenden soll. Die Verwendung von mehr als einem Sec-WebSocket-Extension Header in einer Anfrage ist erlaubt; das Ergebnis ist dasselbe, als ob Sie alle aufgelisteten Erweiterungen in einem solchen Header enthalten hätten.

Sec-WebSocket-Extensions: extensions

extensions

Eine durch Kommas getrennte Liste von Erweiterungen, die angefordert (oder zu unterstützen vereinbart) werden. Diese sollten aus dem IANA WebSocket Extension Name Registry ausgewählt werden. Erweiterungen, die Parameter annehmen, tun dies durch Verwenden von Semikolon-Abgrenzungen.

Beispiel:

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

Sec-WebSocket-Key

Stellt dem Server Informationen zur Verfügung, die erforderlich sind, um zu bestätigen, dass der Client berechtigt ist, ein Upgrade zu WebSocket anzufordern. Dieser Header kann verwendet werden, wenn unsichere (HTTP) Clients ein Upgrade anstreben, um einen gewissen Schutz gegen Missbrauch zu bieten. Der Wert des Schlüssels wird mit einem im WebSocket-Standard definierten Algorithmus berechnet, sodass dies keine Sicherheit bietet. Stattdessen hilft es zu verhindern, dass Nicht-WebSocket-Clients versehentlich oder durch Missbrauch eine WebSocket-Verbindung anfordern. Im Wesentlichen bestätigt dieser Schlüssel dann: „Ja, ich möchte wirklich eine WebSocket-Verbindung öffnen.“

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

Sec-WebSocket-Key: key

key

Der Schlüssel für diese Upgrade-Anforderung. Der Client fügt dies hinzu, wenn er es wünscht, und der Server wird in der Antwort einen eigenen Schlüssel einschließen, den der Client validieren wird, bevor er die Upgrade-Antwort an Sie liefert.

Der Sec-WebSocket-Accept Header der Serverantwort wird einen Wert haben, der basierend auf dem angegebenen key berechnet wird.

Sec-WebSocket-Protocol

Der Sec-WebSocket-Protocol Header gibt ein oder mehrere WebSocket-Protokolle an, die Sie verwenden möchten, in der Reihenfolge der Präferenz. Der erste, der vom Server unterstützt wird, wird ausgewählt und vom Server in einem Sec-WebSocket-Protocol Header in der Antwort zurückgesandt. Sie können dies auch mehrmals im Header verwenden; das Ergebnis ist dasselbe wie bei einer durch Kommas getrennten Liste von Subprotokoll-Bezeichnern in einem einzelnen Header.

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 werden oder ein benutzerdefinierter Name sein, der vom Client und Server gemeinsam verstanden wird.

Sec-WebSocket-Version

Anfrageheader

Spezifiziert die Version des WebSocket-Protokolls, die der Client verwenden möchte, damit der Server bestätigen kann, ob diese Version auf seiner Seite unterstützt wird.

Sec-WebSocket-Version: version

version

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

Antwortheader

Wenn der Server nicht mit der angegebenen Version des WebSocket-Protokolls kommunizieren kann, wird er mit einem Fehler (wie zum Beispiel 426 Upgrade Required) antworten, das in seinen Headers einen 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 kein Sec-WebSocket-Version Header in der Antwort enthalten.

Sec-WebSocket-Version: supportedVersions

supportedVersions

Eine durch Kommas getrennte Liste der vom Server unterstützten WebSocket-Protokollversionen.

Die Antwort des Servers kann diese enthalten.

Sec-WebSocket-Accept

Wird in der Antwortnachricht des Servers während des Eröffnungs-Handshake-Prozesses enthalten sein, wenn der Server bereit ist, eine WebSocket-Verbindung zu initiieren. Es wird nicht öfter als einmal in den Antwort-Headern erscheinen.

Sec-WebSocket-Accept: hash

hash

Wenn ein Sec-WebSocket-Key Header bereitgestellt wurde, wird der Wert dieses Headers berechnet, indem der Wert des Schlüssels genommen und die Zeichenkette "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" daran angehängt wird. Dann wird der SHA-1-Hash dieser verketteten Zeichenkette genommen, was zu einem 20-Byte-Wert führt. Dieser Wert wird dann base64 kodiert, um den Wert dieser Eigenschaft zu erhalten.

• WebSocket-API

• HTTP

• Spezifikationen und RFCs:

  • RFC 7230
  • RFC 6455
  • RFC 7540