[313] Upgrade:
ヘッダーは、
同じ接続を使って HTTP/1.1 から他のプロトコルへと移行するための仕組みです
>>311。事実上 WebSocket 専用であり、 WebSocket接続の確立で使います。
[20] Upgrade:
は、HTTP/1.1 から WebSocket
に切り替えるために使います。
Upgrade
」という名前にしたのでしょうが、 WebSocket
が HTTP の「upgrade」版というわけでもありません。[438] Upgrade:
は、下位層プロトコルの切り替えには使えません >>311。
また、現在の接続を再利用しない切り替えにも使えません >>311。
[314] クライアントは、Upgrade:
ヘッダーを要求に含めることができます
>>311。
Upgrade:
を送信しても、
鯖が切り替えを示すまでは、 HTTP/1.1 のままです。 Upgrade:
が含まれるメッセージは最後まで HTTP/1.1 でなければなりません。[316] Upgrade:
ヘッダーは、クライアントが鯖に対して、
最後の要求を送る前に指定したいずれかのプロトコルに切り替えることを要請するものです >>311。
プロトコルの順序は、優先順を表しています >>311。
[435] このヘッダーは HTTP/1.1 で定義されています。 HTTP/1.0 や HTTP/0.9 では使えません。
[14] HTTP/2 では Upgrade:
を生成してはなりません
>>18。
状態符号 101
も使えないことになっています。
[322] 鯖は、 101
応答に新しいプロトコルを表す
Upgrade:
ヘッダーを含めなければなりません >>311。
複数の階層のプロトコルを切り替える場合には、昇順にしなければなりません
>>311。
[327] 鯖は、 426
応答において
移行可能なプロトコルを示す Upgrade:
ヘッダーを送らなければなりません >>311。
プロトコルの順序は、優先順を表します >>311。
[428] 鯖は、その他の応答にも、移行可能なプロトコルを表す
Upgrade:
ヘッダーを含めて構いません >>311。
プロトコルの順序は、優先順を表します >>311。
[21] Upgrade:
を指定する要求の
HTTP接続における位置は特に規定されていません。
接続を開いて最初の要求でも構いませんし、
途中でも構わないようです。
[441] 鯖は、 Upgrade:
要求に対し、
新しいプロトコルを選んで、 101
応答を返します。ただし、
[437] 鯖は、 Upgrade:
ヘッダーの他に
Expect:
ヘッダーの値 100-continue
が指定されていた場合には、 101
の前に 100
を送らなければなりません >>311。
[432] 鯖は、 Upgrade:
を送信するときは、
Connection:
ヘッダーにも接続オプション
upgrade
を送信しなければなりません >>311。
[17] HTTP/1.0/HTTP/1.1 から HTTP/2 に変換する中間器は、
Connection:
に Upgrade
が明示されているか否かに関わらず、 Upgrade:
ヘッダーがあれば削除するべきです >>18。
[429] プロトコルの切り替え後の能力や性質は、新しいプロトコルに完全に依存します
>>311。しかし、鯖は 101
応答を送信した直後には、
元の要求に対する処理に相当するものを実行することが期待されています >>311。
鯖は、新しいプロトコルが要求の意味を尊重できる場合を除き、
切り替えてはなりません >>311。 OPTIONS
要求は、どんなプロトコルでも尊重される >>311 とされています。
GET
要求を使っていますが、
必ずしも GET
要求に対する応答に相当するものであるとは言えませんし、
この HTTP の本来の想定に沿っているようには見えません。[4] クライアントが対応していない 101
応答を受信した場合のクライアントの処理は、101
を参照してください。
[22] 切り替えが完了する前にクライアントが Upgrade:
を含む要求の次のデータを送信することは、明確には禁止されていません。
一方でサーバーがそれをどう処理するべきかも明確な規定はありません。
サーバーが 101
応答を返す前にクライアントによって送信されていたデータがどこまでであるかをサーバーが判定する方法はありませんから、
サーバーは要求の後の部分はすべて切り替え後のデータと解釈するしかありません。
[5] 現在広く用いられているのは、 WebSocket です。その手順は WebSocket接続の確立を参照してください。
[9] HTTP/2 は Upgrade: h2c
による HTTP/2 over TCP
への切り替えを規定しています。しかしすべての実装が対応しているわけではありません。
[6] 過去に IETF は Upgrade: TLS
により HTTP over TLS
を実現することを試みましたが、失敗しました。
Upgrade: TLS
の歴史の項を参照。[11] サーバーは、 h2
が指定されても無視しなければなりません
>>10。
[7] その他いくつかのプロトコル (HTTP)の値が限られた範囲で使われているようです。
[8] サーバーもクライアントも切り替え後のプロトコルの動作を把握しておく必要がありますから、 一般性を持たせた実装は困難かもしれません。今後次々と新しいプロトコルが登場する見込みもありませんから (HTTP/2 同様、ALPN を使うことになるでしょう。)、 そのような実装の必要も無さそうです。
[3] RFC 2817 は HTTP から HTTP over TLS への切り替えに
Upgrade: TLS/1.0
を使うことを提案していました >>307
(が普及しませんでした)。
[443] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( ( 版)) http://tools.ietf.org/html/rfc3507#page-13
[442] RTSP と SIP には、 Upgrade:
はありません。
[2] プロトコルの切り替えを伴わないクライアントからの要望を伝えるものとして、
Expect:
、Prefer:
、
Accept:
などにたようなヘッダーが他にもあります。
[16] CONNECT
要求メソッドは、実質的に HTTP
を終了させてトンネルに移行するものですが、 Upgrade:
は使っていません。
[30] Apache は Upgrade: h2c
に対応しているから、それは良いとして、
Upgrade: h2
は何だろう。。。
[31] HTTP/2 | 2020 | The Web Almanac by HTTP Archive () https://almanac.httparchive.org/en/2020/http2#upgrade