Upgrade
Der HTTP 1.1 (nur) Upgrade
-Header kann verwendet werden, um eine bereits etablierte Client/Server-Verbindung zu einem anderen Protokoll (über dasselbe Transportprotokoll) zu aktualisieren. Zum Beispiel kann ein Client damit eine Verbindung von HTTP 1.1 auf HTTP 2.0 oder eine HTTP- bzw. HTTPS-Verbindung in einen WebSocket upgraden.
Warnung: HTTP/2 untersagt ausdrücklich die Verwendung dieses Mechanismus/Headers; er ist spezifisch für HTTP/1.1.
Header-Typ | Request-Header, Response-Header |
---|---|
Verbotener Header-Name | ja |
Übersicht
Der Upgrade
-Header kann von Clients verwendet werden, um einen Server einzuladen, zu einem (oder mehreren) der aufgelisteten Protokolle zu wechseln, in absteigender Reihenfolge der Präferenz.
Beispielsweise könnte der Client eine GET
-Anfrage wie gezeigt senden und die bevorzugten Protokolle, zu denen gewechselt werden soll, angeben (in diesem Fall „example/1“ und „foo/2“):
GET /index.html HTTP/1.1
Host: www.example.com
Connection: upgrade
Upgrade: example/1, foo/2
Hinweis: Connection: upgrade
muss gesetzt werden, wann immer Upgrade
gesendet wird.
Der Server kann die Anfrage aus beliebigem Grund ignorieren, in welchem Fall er einfach so antworten sollte, als wäre der Upgrade
-Header nicht gesendet worden (zum Beispiel mit einem 200 OK
).
Wenn der Server sich entscheidet, die Verbindung zu aktualisieren, muss er:
-
Einen
101 Switching Protocols
-Antwortstatus mit einemUpgrade
-Header senden, der das oder die Protokolle angibt, zu denen gewechselt wird. Zum Beispiel:httpHTTP/1.1 101 Switching Protocols Upgrade: foo/2 Connection: Upgrade
-
Eine Antwort auf die ursprüngliche Anfrage unter Verwendung 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 mit dem aktuellen Protokoll nicht ausführen wird, dies jedoch möglicherweise tut, wenn das Protokoll geändert wird. Der Client kann dann einen Protokollwechsel mit dem oben beschriebenen Prozess anfordern.
Weitere Details und Beispiele finden Sie im Thema Protokoll-Upgrade-Mechanismus.
Syntax
Connection: upgrade
Upgrade: protocol_name[/protocol_version]
Anmerkungen:
- Der
Connection
-Header mit dem Typupgrade
muss immer zusammen mit demUpgrade
-Header gesendet werden (wie oben gezeigt). - Protokolle werden kommasepariert in absteigender Präferenz aufgelistet. Die Protokollversion ist optional. Zum Beispiel:
Connection: upgrade
Upgrade: a_protocol/1, example, another_protocol/2.2
Direktiven
- jede kommaseparierte Liste von Protokollnamen (jeweils mit optionaler Protokollversion)
-
Ein oder mehrere Protokollnamen mit optionaler Version (durch "/" getrennt). Die Protokolle sind in absteigender Präferenzreihenfolge aufgeführt.
Beispiele
Connection: upgrade
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
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
- Protokoll-Upgrade-Mechanismus
101
Switching Protocol
426
Upgrade Required
Connection