Protokoll-Upgrade-Mechanismus

Das Upgrade-Headerfeld wird von Clients verwendet, um den Server einzuladen, auf eines der aufgelisteten Protokolle in absteigender Präferenz zu wechseln.

Da Upgrade ein Hop-by-Hop-Header ist, muss es auch im Connection-Headerfeld aufgelistet werden. Das bedeutet, dass eine typische Anfrage, die ein Upgrade einschließt, 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; beispielsweise erlauben WebSocket-Upgrades zusätzliche Header, um Details über die WebSocket-Verbindung zu konfigurieren sowie ein gewisses Maß an Sicherheit beim Öffnen der Verbindung zu bieten. Siehe Upgrade auf eine WebSocket-Verbindung für weitere Details.

Wenn der Server entscheidet, die Verbindung aufzurüsten, sendet er einen 101 Switching Protocols-Antwortstatus mit einem Upgrade-Header zurück, der das oder die Protokolle spezifiziert, zu denen gewechselt wird. Wenn er das nicht tut (oder nicht kann), ignoriert er das Upgrade-Headerfeld und sendet eine reguläre 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 alle zusätzlichen protokollspezifischen Handshakes durchzuführen, falls erforderlich. Effektiv wird die Verbindung zu einer Zwei-Wege-Leitung, 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 das Upgrade-Headerfeld.

Bei weitem der häufigste Anwendungsfall für das Upgrade einer HTTP-Verbindung ist die Verwendung von WebSockets, die immer durch das Upgrade einer HTTP- oder HTTPS-Verbindung implementiert werden. Beachten Sie, dass, wenn Sie eine neue Verbindung über die WebSocket-API oder eine beliebige Bibliothek, die WebSockets verwendet, öffnen, die meisten oder alle dieser Schritte für Sie ausgeführt werden. Zum Beispiel ist das Öffnen einer WebSocket-Verbindung so einfach wie:

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

Der WebSocket()-Konstruktor übernimmt die gesamte Arbeit, eine initiale HTTP/1.1-Verbindung zu erstellen und anschließend den Handshake und den Upgrade-Prozess für Sie durchzuführen.

Wenn Sie eine WebSocket-Verbindung von Grund auf neu erstellen müssen, müssen Sie den Handshake-Prozess selbst durchführen. Nach der Erstellung der initialen HTTP/1.1-Sitzung müssen Sie das Upgrade anfordern, indem Sie zu einer standardmäßigen Anfrage die Upgrade- und Connection-Header hinzufügen, wie folgt:

Connection: Upgrade
Upgrade: websocket

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

Sec-WebSocket-Extensions

Gibt eine oder mehrere auf Protokollebene befindliche WebSocket-Erweiterungen an, 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 wenn Sie alle gelisteten Erweiterungen in einem solchen Header enthalten hätten.

Sec-WebSocket-Extensions: extensions

extensions

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

Zum Beispiel:

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

Sec-WebSocket-Key

Stellt dem Server Informationen bereit, die benötigt werden, um zu bestätigen, dass der Client berechtigt ist, ein Upgrade auf WebSocket anzufordern. Dieser Header kann verwendet werden, wenn unsichere (HTTP) Clients ein Upgrade wünschen, um ein gewisses Maß an Schutz gegen Missbrauch zu bieten. Der Wert des Schlüssels wird gemäß einem im WebSocket-Spezifikation definierten Algorithmus berechnet, sodass dies keine Sicherheit bietet. Stattdessen hilft es, unbeabsichtigte oder missbräuchliche Anfragen nach einer WebSocket-Verbindung von Nicht-WebSocket-Clients zu verhindern. Im Wesentlichen bestätigt dieser Schlüssel dann, dass "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 über die 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 dies wünscht, und der Server wird in der Antwort einen eigenen Schlüssel enthalten, den der Client validieren wird, bevor er die Upgrade-Antwort an Sie liefert.

Der Sec-WebSocket-Accept-Header der Serverantwort wird einen basierend auf dem angegebenen key berechneten Wert enthalten.

Sec-WebSocket-Protocol

Der Sec-WebSocket-Protocol-Header spezifiziert ein oder mehrere WebSocket-Protokolle, die Sie verwenden möchten, in bevorzugter Reihenfolge. 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 mehrfach im Header verwenden; das Ergebnis ist dasselbe, als ob Sie eine durch Kommas getrennte Liste von Subprotokollkennungen in einem einzigen 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 werden oder können ein benutzerdefinierter Name sein, der vom Client und Server gemeinsam verstanden wird.

Sec-WebSocket-Version

Anfrage-Header

Gibt die WebSocket-Protokollversion an, die der Client verwenden möchte, sodass der Server bestätigen kann, ob diese Version auf seiner Seite unterstützt wird.

Sec-WebSocket-Version: version

version

Die WebSocket-Protokollversion, die der Client im Kommunikationsprozess mit dem Server verwenden möchte. Diese Nummer sollte die neueste mögliche Version sein, die im IANA WebSocket Version Number Registry gelistet ist. Die neueste endgültige Version des WebSocket-Protokolls ist Version 13.

Antwort-Header

Wenn der Server nicht mit der angegebenen Version des WebSocket-Protokolls kommunizieren kann, wird er mit einem Fehler antworten (wie 426 Upgrade Required), der in seinen Headern 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 die Antwort aufgenommen.

Sec-WebSocket-Version: supportedVersions

supportedVersions

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

Die Antwort vom Server kann diese einschließen.

Sec-WebSocket-Accept

In der Antwortnachricht vom Server während des Eröffnungshandshake-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 der Wert des Schlüssels genommen wird, die Zeichenfolge "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" daran angehängt wird, den SHA-1-Hash dieses zusammengefügten Strings ermittelt wird, was in einem 20-Byte-Wert resultiert. Dieser Wert wird dann base64 kodiert, um den Wert dieses Attributs zu erhalten.

• WebSocket-API
• Entwicklung von HTTP
• Glossarbegriffe:
  • HTTP
  • HTTP/2
  • QUIC