[313] Upgrade:
ヘッダーは、
同じ接続を使って HTTP/1.1 から他のプロトコルへと移行するための仕組みです
>>311。事実上 WebSocket 専用であり、 WebSocket接続の確立で使います。
[20] Upgrade:
は、HTTP/1.1 から WebSocket
に切り替えるために使います。
Upgrade
」という名前にしたのでしょうが、 WebSocket
が HTTP の「upgrade」版というわけでもありません。[438] Upgrade:
は、下位層プロトコルの切り替えには使えません >>311。
また、現在の接続を再利用しない切り替えにも使えません >>311。
[319] 欄値は、1つ以上のプロトコルのリスト (#
) です >>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 を使うことになるでしょう。)、 そのような実装の必要も無さそうです。
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 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:
は使っていません。
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.
Upgrade: h2,h2c
Connection: Upgrade
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] Apache は Upgrade: h2c
に対応しているから、それは良いとして、
Upgrade: h2
は何だろう。。。
[31] HTTP/2 | 2020 | The Web Almanac by HTTP Archive () https://almanac.httparchive.org/en/2020/http2#upgrade