[102] HTTP の状態符号 101 は、 プロトコルを HTTP/1.1 以外に切り替えることを表します。

[103] この応答までは HTTP/1.1 ですが、その後は新しいプロトコルに切り替わります。

[107] HTTP の鯖もクライアントも、 HTTP 以外のプロトコルの実装は特に義務付けられていません。しかし、 HTTP/1.1 のクライアントは、 101 を含む 1xx の応答の構文解析には対応しなければなりません。

[106] この状態符号は Upgrade: ヘッダーと共に使われます。 用法と処理モデルについては、 Upgrade: の項も参照してください。

仕様書

意味

[112] 101 状態符号は、 クライアントが Upgrade: ヘッダーで示した本接続で利用するアプリケーションプロトコルの変更の要求を鯖が理解し、 従う意思があることを示しています。 >>111

構文

[113] 鯖は、 101 応答に Upgrade: ヘッダーを生成しなければなりません >>101。

文脈

[108] HTTP/1.0 クライアントに 101 を含む 1xx の応答を送ってはなりません。

[6] HTTP/2 では 101 応答は使えません >>5。

処理

[109] HTTP/1.1 のクライアントは、 101 を含む 1xx の構文解析に対応しなければなりません。

[110] HTTP/1.1 の串は、自身が 1xx 応答を特に要求した場合を除き、 101 を含む 1xx 応答を転送しなければなりません。

[1] HTTP/1.0 応答が 101 応答だった時にクライアントがどう処理するべきかは不明です。

[2] クライアントが理解できない 101 応答を受信した時にどうしなければならないのかは不明です。

[3] サーバーは 101[応答の後直ちにプロトコルを切り替えることになっています。 クライアントは切り替えが可能かどうか表明する方法がありません (本来クライアントの指示にサーバーが応えて切り替えるはずのものですから)。 従ってクライアントが処理できないデータを受け取ることになりますから、 持続接続の利用の有無に関わらず、クライアントは直ちにHTTP接続を閉じ、 受信データがあったとしても捨てるべきと思われます。

[4] クライアントがその場合に fetch のような API でどう処理するべきかも明確ではありません。 101 応答を結果として返すかもしれませんし、 最後の応答ではないのですから、ネットワークエラーとするべきかもしれません。

[104] Upgrade: の項も参照してください。

[7] Chrome と IE は、 101 も (少なくても XHR では) 他の 1xx と同じく無視し、その後に最後の要求があればそれを結果として採用するようです。 (XHR では要求に Upgrade: は指定できないため、 応答に Upgrade: が含まれていても、プロトコルの切り替えを表すのではなく、 切り替え可能なプロトコルを示していると解釈するべきと思われます。)

[8] Firefox は、 (XHR では) 101 応答を結果として採用するようです。

[9] HTTP/2 RFC は 101 応答をどう処理するべきか規定していません。

[10] Firefox は HTTP/2 101 を受信したら、 ストリームエラー PROTOCOL_ERROR とします。

歴史

RFC 2068・2616 (HTTP/1.1) 10.1.2 101 Switching Protocols

The server understands and is willing to comply with the client's request, via the Upgrade message header field (section 14.41 14.42), for a change in the application protocol being used on this connection. The server will switch protocols to those defined by the response's Upgrade header field immediately after the empty line which terminates the 101 response.

サーバーは、この接続で使用する応用プロトコルの変更に関して、 Upgrade メッセージ頭欄を通じたクライアントの要求を理解し、 それに従う意思があります。 サーバーは 101 応答の終端である空行の直後に応答の Upgrade 頭欄で定義されたプロトコルに切り替えます。

The protocol should only be switched SHOULD be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over older versions, and switching to a real-time, synchronous protocol may might be advantageous when delivering resources that use such features.

プロトコルの切り替えは、そうすることに利点がある場合にのみ行われるべきです。 例えば、新しい版の HTTP に切り替えることは古い版より有利ですし、 実時刻同期プロトコルに切り替えることはこの機能を使った資源を配送する時には有利です。

関連

[105] 100 と 101 の送信順序については、 Upgrade: を参照してください。

[11] Docker Remote API v1.19 - Docker () https://docs.docker.com/engine/reference/api/docker_remote_api_v1.19/

Example request:

GET /containers/4fa6e0f0c678/logs?stderr=1&stdout=1&timestamps=1&follow=1&tail=10&since=1428990821 HTTP/1.1

Example response:

HTTP/1.1 101 UPGRADED

Content-Type: application/vnd.docker.raw-stream

Connection: Upgrade

Upgrade: tcp

{{ STREAM }}