Upgrade header

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

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

Header-Typ Anforderungs-Header, Antwort-Header
Verbotener Anforderungs-Header Ja

Syntax

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

Direktiven

<protocol>

Protokolle werden, durch Kommas getrennt, in absteigender Präferenzreihenfolge aufgelistet.

<protocol_version> Optional

Eine optionale Protokollversion kann mit einem /-Schrägstrich vorangestellt werden.

Beschreibung

Das Upgrade-Headerfeld kann von Clients verwendet werden, um einen Server einzuladen, zu einem (oder mehreren) der aufgelisteten Protokolle in absteigender Präferenzreihenfolge zu wechseln. Zum Beispiel könnte der Client eine GET-Anfrage senden, wie gezeigt, und die bevorzugten Protokolle zum Wechsel auflisten (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 dem Typ upgrade muss immer zusammen mit dem Upgrade-Header gesendet werden.

Der Server kann die Anfrage aus beliebigen Gründen ignorieren und sollte in diesem Fall antworten, als wäre der Upgrade-Header nicht gesendet worden (zum Beispiel mit einem 200 OK). Wenn der Server die Verbindung upgraden wird, muss er:

  1. Einen Antwortstatus 101 Switching Protocols mit einem Upgrade-Header zurücksenden, der das/die Protokoll(e) spezifiziert, zu dem/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 mittels des neuen Protokolls senden (der Server darf 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, dies aber möglicherweise tut, wenn das Protokoll geändert wird. Der Client kann dann eine Protokolländerung mit dem obigen Prozess anfordern.

Weitere Details und Beispiele sind im Thema Protokoll-Upgrade-Mechanismus bereitgestellt.

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 auf WebSocket

Dies ist eine übliche Kombination von Headern, um mit dem Upgrade einer HTTP-Verbindung auf WebSockets zu beginnen. Siehe Upgrade auf eine WebSocket-Verbindung für weitere Informationen.

http
Connection: Upgrade
Upgrade: websocket

Spezifikationen

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

Browser-Kompatibilität

Siehe auch