Upgrade

Der HTTP Upgrade-Anfrage und Antwort-Header kann verwendet werden, um eine bereits bestehende Client/Server-Verbindung auf ein anderes Protokoll (über dasselbe Transportprotokoll) zu aktualisieren. Zum Beispiel kann ein Client damit eine Verbindung von HTTP/1.1 auf HTTP/2 oder eine HTTP(S)-Verbindung auf eine WebSocket-Verbindung upgraden.

Warnung: HTTP/2 verbietet ausdrücklich die Verwendung dieses Mechanismus und Headers; es ist spezifisch für HTTP/1.1.

Header-Typ Anfrage-Header, Antwort-Header
Verbotener Header-Name Ja

Syntax

Eine durch Kommas getrennte Liste von einem oder mehreren Protokollen:

http
Upgrade: <protocol>[/<protocol_version>]
Upgrade: <protocol>[/<protocol_version>], …, <protocolN>[/<protocol_versionN>]

Direktiven

<protocol>

Protokolle werden in absteigender Präferenz aufgelistet und durch Kommas getrennt.

<protocol_version> Optional

Eine optionale Protokollversion kann angegeben werden, vorangestellt durch einen Schrägstrich /.

Beschreibung

Das Upgrade-Header-Feld kann von Clients verwendet werden, um einen Server einzuladen, zu einem (oder mehreren) der aufgelisteten Protokolle in absteigender Präferenzordnung zu wechseln. Zum Beispiel könnte der Client eine GET-Anfrage senden, wie gezeigt, und die bevorzugten Protokolle angeben, zu denen gewechselt werden soll (in diesem Fall example/1 und foo/2):

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

Hinweis: Der Connection-Header mit Typ upgrade muss immer mit dem Upgrade-Header gesendet werden.

Der Server kann die Anfrage aus irgendeinem Grund ignorieren, in diesem Fall sollte er antworten, als wäre der Upgrade-Header nicht gesendet worden (zum Beispiel mit einem 200 OK). Wenn der Server die Verbindung upgraden möchte, muss er:

  1. Einen 101 Switching Protocols Antwortstatus mit einem Upgrade-Header zurücksenden, der die Protokolle angibt, zu denen gewechselt wird. Zum Beispiel:

    http
    HTTP/1.1 101 Switching Protocols
Upgrade: foo/2
Connection: Upgrade

  2. Eine Antwort auf die ursprüngliche Anfrage unter Verwendung des neuen Protokolls senden (der Server kann nur zu einem Protokoll wechseln, mit dem er die ursprüngliche Anfrage abschließen kann).

Ein Server kann den Header auch als Teil einer 426 Upgrade Required-Antwort senden, um anzuzeigen, dass der Server die Anfrage nicht mit dem aktuellen Protokoll ausführen wird, aber dies möglicherweise tut, wenn das Protokoll geändert wird. Der Client kann dann eine Protokolländerung mit dem oben beschriebenen Prozess anfordern.

Mehr Details und Beispiele finden Sie im Thema Protokoll-Upgrade-Mechanismus.

Beispiele

Upgrade-Header mit mehreren Protokollen

Die folgende Anfrage listet mehrere Protokolle in absteigender Präferenz auf:

http
Connection: upgrade
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

Upgrade zu WebSocket

Dies ist eine häufige Kombination von Headern, um mit dem Upgrade einer HTTP-Verbindung zu WebSockets zu beginnen. Weitere Informationen finden Sie unter Upgrade zu einer WebSocket-Verbindung.

http
Connection: Upgrade
Upgrade: websocket

Spezifikationen

Specification
HTTP Semantics
# field.upgrade
HTTP Semantics
# status.426
HTTP/2
# informational-responses

Browser-Kompatibilität

BCD tables only load in the browser

Siehe auch