[3] HTTP や派生プロトコルでは、百番台の状態符号は要求された処理の途中経過的なものを示す暫定応答を表します。正式な応答はしばらくした後に続けて送られてくるはずです。
[105] 1xx は、要求された動作を完了して最後の応答を送信する前に接続状態や要求の進捗を知らせるための暫定的な応答を表しています
>>104。
[102] 1xx 応答は、メッセージ本体を持ちません
>>101。状態行とヘッダー群の後の最初の空行をもって応答は終わりとなります
>>104。
[110] 1xx でも Connection: close
の意味は特別に規定はされていません。 Connection: close
が指定されていればその応答をもって鯖が接続を閉じることが示されているものと考えられます。
[10] HTTP/2 では、サーバーは応答のヘッダーを表すフレームの前に
0個以上の 1xx 応答を送ることができます。
[9] HTTP/1.1 では、サーバーは最後の応答を送る前に0個以上の
1xx 応答を送ることができます。
[107] クライアントは、 1xx 応答を期待していない場合であっても、
最後の応答の前に 1xx 応答が1つ以上現れるのを構文解析できなければなりません。
期待していない 1xx 応答は無視して構いません。 >>104
[108] 串は、自身が 1xx 応答の生成を要求した場合を除き、
1xx 応答を転送しなければなりません >>104。
[6] クライアントが対応していない 101
応答を受信した場合のクライアントの処理は、101
を参照してください。
[11] HTTP/1.0 応答でも HTTP/1.1 応答でも、
Chrome も Firefox も IE も 1xx
応答を無視するようです。
[14] Chrome も Firefox も IE も、 Content-Length:
ヘッダーや Connection: close
があっても無視します。
[7] クライアントが 1xx を受信した後で最後の応答を受信する前に接続が閉じられた場合に
fetch などの API でどう扱うべきかは定かではありませんが、
1xx 応答を結果と返すべきではないでしょうし、
ネットワークエラーを返すべきかもしれません。
[13] Chrome と IE と Firefox は、 1xx
応答の後接続が閉じられた時、ネットワークエラーとするようです。
[15] Chrome と IE は、 HTTP/1.0/HTTP/1.1 の 1xx
の後は、 HTTP/1.0 か HTTP/1.1 の最後の応答ではなく、 HTTP/0.9
であっても構いません (通常の判定方法を使うようです)。 Firefox
は HTTP/0.9 だとネットワークエラーにします。
[103] RFC 1945 (HTTP/1.0) 9.1; RFC 2068・2616 (HTTP/1.1) 10.1 Informational 1xx
This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. {2616} There are no required headers for this class of status code.
{1945} HTTP/1.0 does not define any 1xx codes and they are not a valid response to a HTTP/1.0 request. However, they may be useful for experimental applications which are outside the scope of this specification.{2068, 2616} Since HTTP/1.0 did not define any 1xx status status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client except under experimental conditions.
この状態符号の級は、暫定応答を示し、 Status-Line
と省略可能な頭並びのみを含み、空行で愁嘆します。 この状態符号の級では必須の頭はありません。 HTTP/1.0 は HTTP/1.0 は 1xx 符号を定義しておらず、 HTTP/1.0 要求に対する妥当な応答ではありません。しかし、この仕様書の適用範囲外の実験的応用には有用かもしれません。1xx 状態符号を定義していませんでしたから、サーバーは HTTP/1.0 クライアントには実験的条件下を除いて 1x 応答を送ってはなりません。
{2616} A client MUST be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 (Continue) status message. Unexpected 1xx status responses MAY be ignored by a user agent.
クライアントは、たとえそのクライアントが 100 (継続)
状態メッセージを期待していないとしても、正規の応答の前の1つ以上の 1xx 状態応答を受け入れる準備ができていなければなりません。
予期せぬ 1xx を利用者エージェントは無視しても構いません。
Proxies MUST forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself requested the generation of the 1xx response. (For example, if a proxy adds a "Expect: 100-continue" field when it forwards a request, then it need not forward the corresponding 100 (Continue) response(s).)
串は、串とそのクライアントの間の接続が閉じているか、
又は串自身が 1xx 応答の生成を要求したのでない限り、
1xx 応用を転送しなければなりません。
(例えば、串が要求を転送するときに Expect: 100-continue
欄を加えたのなら、対応する 100 (継続)
応答(群)を転送する必要はありません。)
[1] 巷の HTTP/1.1 適合を主張する利用者エージェントって、
ほんとに 1xx に対応しているのですかね?
[2] 本体を使えれば、「しばらくお待ち下さい」的メッセージに使えると思うんですが・・・。
multipart/x-mixed-replace
の代替にも使えるかも。
その辺がちょいとばかり残念かも。
[5] mod_proxy_http - Apache HTTP Server Version 2.4 ( 版) <http://httpd.apache.org/docs/current/en/mod/mod_proxy_http.html>
proxy-interim-response
This variable takes values RFC (the default) or Suppress. Earlier httpd versions would suppress HTTP interim (1xx) responses sent from the backend. This is technically a violation of the HTTP protocol. In practice, if a backend sends an interim response, it may itself be extending the protocol in a manner we know nothing about, or just broken. So this is now configurable: set proxy-interim-response RFC to be fully protocol compliant, or proxy-interim-response Suppress to suppress interim responses.