Upgrade

Upgrade: ヘッダー (HTTP)

[313] Upgrade: ヘッダーは、 同じ接続を使って HTTP/1.1 から他のプロトコルへと移行するための仕組みです >>311。事実上 WebSocket 専用であり、 WebSocket接続の確立で使います。

仕様書

意味

[20] Upgrade: は、HTTP/1.1 から WebSocket に切り替えるために使います。

[24] HTTP の改訂版を含め、色々な他のプロトコルへの切り替えを想定していたようですが、 実際に使われているのは WebSocket だけです。
[25] HTTP の改訂版などより高機能なプロトコルへの切り替えを想定して 「Upgrade」という名前にしたのでしょうが、 WebSocketHTTP の「upgrade」版というわけでもありません。

[438] Upgrade: は、下位層プロトコルの切り替えには使えません >>311。 また、現在の接続を再利用しない切り替えにも使えません >>311

構文

[319] 欄値は、1つ以上のプロトコルリスト (#) です >>311

[320] プロトコルは、名前、または名前と / と版を並べたものです >>311

[321] プロトコルの詳細と値の一覧は、 protocol (HTTP) の項を参照してください。

文脈

[314] クライアントは、Upgrade: ヘッダー要求に含めることができます >>311

[436] クライアントUpgrade: を送信しても、 が切り替えを示すまでは、 HTTP/1.1 のままです。 Upgrade: が含まれるメッセージは最後まで HTTP/1.1 でなければなりません。

[316] Upgrade: ヘッダーは、クライアントに対して、 最後の要求を送る前に指定したいずれかのプロトコルに切り替えることを要請するものです >>311プロトコルの順序は、優先順を表しています >>311

[315] Upgrade: ヘッダーは複数指定できます。

[435] このヘッダーHTTP/1.1 で定義されています。 HTTP/1.0HTTP/0.9 では使えません。

[14] HTTP/2 では Upgrade:生成してはなりません >>18状態符号 101 も使えないことになっています。

[322] は、 101 応答に新しいプロトコルを表す Upgrade: ヘッダーを含めなければなりません >>311。 複数の階層のプロトコルを切り替える場合には、昇順にしなければなりません >>311

[324] 昇順ってどちらでしょうか??

[327] は、 426 応答において 移行可能なプロトコルを示す Upgrade: ヘッダーを送らなければなりません >>311プロトコルの順序は、優先順を表します >>311

[428] は、その他の応答にも、移行可能なプロトコルを表す Upgrade: ヘッダーを含めて構いません >>311プロトコルの順序は、優先順を表します >>311

[21] Upgrade: を指定する要求HTTP接続における位置は特に規定されていません。 接続を開いて最初の要求でも構いませんし、 途中でも構わないようです。

処理

[441] は、 Upgrade: 要求に対し、 新しいプロトコルを選んで、 101 応答を返します。ただし、

[427] 101 応答は新しいプロトコルではなく、 まだ HTTP/1.1 のままです。
C
クライアント
S
C -> S
要求
Upgrade: P
Connection: upgrade
S -> C
101 応答
Upgrade: P
Connection: upgrade
C ## S
P に移行

[437] は、 Upgrade: ヘッダーの他に Expect: ヘッダーの値 100-continue が指定されていた場合には、 101 の前に 100 を送らなければなりません >>311

[432] は、 Upgrade: を送信するときは、 Connection: ヘッダーにも接続オプション upgrade を送信しなければなりません >>311

[433] これによって、中間器が指定されたプロトコルに対応していない時に切り替えを防ぐことができます。
[1] 防ぐことはできますが、キャッシュの処理と Upgrade: は矛盾するので、キャッシュ可能メソッドUpgrade: を使うのは得策ではなさそうです。

[17] HTTP/1.0/HTTP/1.1 から HTTP/2 に変換する中間器は、 Connection:Upgrade が明示されているか否かに関わらず、 Upgrade: ヘッダーがあれば削除するべきです >>18

[19] HTTP/2 では、 Upgrade: が含まれるメッセージ奇形です >>18

プロトコルの切り替え

[429] プロトコルの切り替え後の能力や性質は、新しいプロトコルに完全に依存します >>311。しかし、101 応答を送信した直後には、 元の要求に対する処理に相当するものを実行することが期待されています >>311は、新しいプロトコル要求の意味を尊重できる場合を除き、 切り替えてはなりません >>311OPTIONS 要求は、どんなプロトコルでも尊重される >>311 とされています。

[430] 例えば GET 要求Upgrade: が指定されていて、101 を返した場合、 は新しいプロトコルに切り替えて GET されていた資源を送るべきです。

[431] 従って、特に実行したい HTTP 操作がなく、プロトコルの切り替えだけを行いたいときは、 OPTIONS 要求を使えば良いことになります。
[26] WebSocketGET 要求を使っていますが、 必ずしも GET 要求に対する応答に相当するものであるとは言えませんし、 この HTTP の本来の想定に沿っているようには見えません。

[4] クライアントが対応していない 101 応答を受信した場合のクライアントの処理は、101 を参照してください。

[22] 切り替えが完了する前にクライアントUpgrade: を含む要求の次のデータを送信することは、明確には禁止されていません。 一方でサーバーがそれをどう処理するべきかも明確な規定はありません。 サーバー101 応答を返す前にクライアントによって送信されていたデータがどこまでであるかをサーバーが判定する方法はありませんから、 サーバー要求の後の部分はすべて切り替え後のデータと解釈するしかありません。

[23] サーバーが切り替えを拒否した場合は、そのデータは HTTP として解釈されることになります。

具体的な切り替え手順

[5] 現在広く用いられているのは、 WebSocket です。その手順は WebSocket接続の確立を参照してください。

[9] HTTP/2Upgrade: h2c による HTTP/2 over TCP への切り替えを規定しています。しかしすべての実装が対応しているわけではありません。

HTTP接続を参照。

[6] 過去に IETFUpgrade: TLS により HTTP over TLS を実現することを試みましたが、失敗しました。

Upgrade: TLS の歴史の項を参照。

[11] サーバーは、 h2 が指定されても無視しなければなりません >>10

[12] HTTP/2 over TLS では ALPN が使われ、 Upgrade: は使えません。
[13] この規定より h2 という値は使えないはずですが、 IANA登録簿には予約としても登録されていないようです。

[7] その他いくつかのプロトコル (HTTP)の値が限られた範囲で使われているようです。

[8] サーバークライアントも切り替え後のプロトコルの動作を把握しておく必要がありますから、 一般性を持たせた実装は困難かもしれません。今後次々と新しいプロトコルが登場する見込みもありませんから (HTTP/2 同様、ALPN を使うことになるでしょう。)、 そのような実装の必要も無さそうです。

歴史

[308] RFC 2068 (HTTP/1.1) 14.41; RFC 2616 (HTTP/1.1) 14.42 Upgrade

The Upgrade general-header allows the client to specify what additional communication protocols it supports and would like to use if the server finds it appropriate to switch protocols. The server MUST use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched.

Upgrade 一般頭欄は、 クライアントが、どの追加の通信プロトコルに対応しており、 がプロトコル切替えが適切であると判断した場合には使用したいと考えているのかを指定することができます。 鯖は、 101 (プロトコル切替) 応答中でどのプロトコルに切り替えるのかを示すために Upgrade 頭欄を使わなければなりません

  • Upgrade = "Upgrade" ":" 1#product

For example,

  • Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult transition between incompatible protocols by allowing the client to initiate a request in the more commonly supported protocol while indicating to the server that it would like to use a "better" protocol if available (where "better" is determined by the server, possibly according to the nature of the method and/or resource being requested).

Upgrade 頭欄は、 HTTP/1.1 から何か他の、非互換なプロトコルに移行するための単純な機構を提供することを想定しています。クライアントは、 現在の要求は HTTP/1.1 を使って行いながらも、例えばより大きな大版番号を持つより新しい版の HTTP のような、別のプロトコルを使いたいと思っているということを宣伝できます。 これによって、非互換プロトコル間の難しい移行が、 クライアントはより広く対応されているプロトコルで要求を初期化しつつ鯖に「よりよい」 プロトコルを利用可能なら使いたいことを示すことができるので、 容易になります。 (ここで「よりよい」とは、鯖によって、おそらく要求された方式及び/又は資源の性質に従って決定されます。)

The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection. Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen, although the first action after changing the protocol MUST be a response to the initial HTTP request containing the Upgrade header field.

Upgrade 頭欄は、既存の転送層接続上の応用層プロトコルの切替にのみ適用します。 Upgrade をプロトコル変更を主張するのに使うことはできません。 鯖がそれを受け入れて使用するかどうかは任意選択です。 プロトコル変更後の応用層通信の能力と性質は選ばれた新しいプロトコルに完全に依存します。 但し、プロトコル変更後の最初の動作は Upgrade 頭欄を含んだ初期 HTTP 要求への応答でなければなりません

The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword MUST be supplied within a Connection header field (section 14.10) whenever Upgrade is present in an HTTP/1.1 message.

Upgrade 頭欄は、直接接続にのみ適用します。 従って、 Upgrade が HTTP/1.1 メッセージ中に存在するときには、 必ず upgrade 見出し語を Connection 頭欄中に供給しなければなりません

The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it is more appropriate to use a 301, 302, 303, or 305 redirection response.

Upgrade 頭欄は、異なる接続上のプロトコルへの切替えを示すために使うことはできません。 その目的には、 301, 302, 303 または 305 の再指向応答を使うのがより適切です。

This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined by the HTTP version rules of section 3.1 and future updates to this specification. Any token can be used as a protocol name; however, it will only be useful if both the client and server associate the name with the same protocol.

この仕様書は、プロトコル名 HTTP だけを、 ハイパー文転送プロトコルで使用するために、 3.1節の版規則とこの仕様書の将来の更新で定義される通り定義します。 任意の字句をプロトコル名として使うことができます。 しかし、それはクライアントと鯖がある名前を同じプロトコルと関連付けている場合に限って有用です。

[3] RFC 2817HTTP から 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] RTSPSIP には、 Upgrade: はありません。

[2] プロトコルの切り替えを伴わないクライアントからの要望を伝えるものとして、 Expect:Prefer:Accept: などにたようなヘッダーが他にもあります。

[16] CONNECT 要求メソッドは、実質的に HTTP を終了させてトンネルに移行するものですが、 Upgrade: は使っていません。

[27] GDAX | API Reference () <https://docs.gdax.com/#sandbox-urls>

FIX API

https://fix-public.sandbox.gdax.com

NOTE ON FIX API

request.end();

When connecting to the FIX API in Sandbox, you must start with an HTTP Upgrade request and set the Upgrade header to fix. After receiving a 101 Switching Protocols response from the server, you may continue using the connection as a regular FIX connection. Remember to use HTTPS for this.

[28] 58745 – H2Upgrade do not works ( ()) <https://bz.apache.org/bugzilla/show_bug.cgi?id=58745>

Upgrade: h2,h2c

Connection: Upgrade

[29] Handling server replies with "Upgrade" header (HTTP/2 switch) · Issue #81 · jech/polipo ( ()) <https://github.com/jech/polipo/issues/81>

Server: Apache/2.4.18 (Unix)

X-Powered-By: PHP/5.6.15

Vary: Accept-Encoding,Cookie

Cache-Control: max-age=3, must-revalidate

WP-Super-Cache: Served supercache file from PHP

Upgrade: h2,h2c

[30] ApacheUpgrade: h2c に対応しているから、それは良いとして、 Upgrade: h2 は何だろう。。。