[1] 100 Continue
応答は、クライアントが要求を途中まで送ってきたところで、サーバーが (その時点では) 問題はないから続きを送りたまえという意思表示をするものです。
[441] 100
を含む 1xx
応答は、
最後の応答の前に途中の状態や進捗を表す応答です。
200
以上の最後の応答よりも前に、
鯖は0個以上の 1xx
応答を送ることが認められています。
[447] HTTP/1.1 では鯖もクライアントも 100
に対応することが求められているようですが、実際どれだけ対応されているのかは不明です。
使われているという話はあまり聞きません。
[444] 100
状態符号は、要求の最初の部分が受信され、
鯖はその時点で拒絶はしていないことを示しています。
鯖は、要求を完全に受信し、それに従い動作した後、
最後の応答を送ることとなります。 >>443
[445] 要求が Expect: 100-continue
(>>424)
を含む場合には、鯖が payload body の受信を望むことを示します。
>>443
[439] HTTP/1.1 クライアントは 100
を含む 1xx
応答の構文解析を実装しなければなりません。
[446] クライアントは、要求に Expect: 100-continue
を含めなかった場合、 100
応答を捨てて構いません >>443。
[440] 串は自身が 100
を含む 1xx
応答を要求した場合を除き、これを転送しなければなりません。
串自身が要求に 100
の要求を追加して転送した場合は、
100
を転送する必要はありません。
100-continue
[424] Expect:
ヘッダーの値 100-continue
は、クライアントが (おそらく大きな)
メッセージ本体を当該要求のメッセージ本体で送信しようとしており、
要求行とヘッダーのみから即座に成功、リダイレクト、エラーのいずれかの応答を返すことができなければ
100
応答を受信したいと望んでいることを、
受信者に通知するものとなっています >>420。
[425] これによりクライアントはメッセージ本体を送信する前に送信する意味があるか判断できますから、 メッセージ本体が大きい時やエラーになりそうな時に効率を向上させることができます >>420。
[427] クライアントは、メッセージ本体を送る前に 100
応答を待つ場合、 100-continue
を送信しなければなりません
>>420。
[428] クライアントが 100-continue
を送信する場合、
待つ時間に特に決まりはありません。応答を受信しなくても、
メッセージ本体を送信して構いません。特に、 HTTP/1.0
中間器は仕組み上 100
応答を送れませんから、
メッセージ本体を送信するまでいつまでも待つべきではありません。 >>420
[426] クライアントは、メッセージ本体を含まない要求に
100-continue
を生成してはなりません >>420。
[430] 鯖は、 HTTP/1.0 要求で 100-continue
を受信した場合、これを無視しなければなりません >>421。
[431] 鯖は、メッセージ本体の一部又は全部を既に受信した場合や、
メッセージ本体がないと示されているときは、 100
の送信を省略して構いません >>420。
[434] 起源鯖は、 HTTP/1.1 以降の要求行とヘッダー部全体を読み終わったら、
そこから状態符号を決定できる場合には最終的な状態符号で即座の応答を送信するか、
または即座の 100
応答を送信してメッセージ本体の送信を促すかのいずれかとしなければなりません
>>420。起源鯖は 100
応答を送信する前にメッセージ本体を待ってはなりません
>>420。
[435] 串は、 HTTP/1.1 以降の要求行とヘッダー部全体を読み終わったら、 そこから状態符号を決定できる場合には最終的な状態符号で即座の応答を送信するか、 または要求行とヘッダー部を上流に転送するかしなければなりません。 >>420
[436] 串は、内向きの鯖が HTTP/1.0 しか対応していないと
(設定や経験から) 考えられるときは、即座の 100
応答を送信してメッセージ本体の送信を促しても構いません >>420。
[422] 鯖は、 100-continue
と Upgrade:
が共に指定されているときは、まず 100
を送り、次に
101
を送ります >>421。
[432] 鯖は、 100
を送った場合、
メッセージ本体を受信して処理したら、 (接続が途中で閉じられた場合を除き、)
最終的な状態符号の応答を送信しなければなりません >>420。
[433] 鯖は、メッセージ本体をすべて読む前に最終的な状態符号の応答を送信する場合、
接続を閉じることを応答に示す (Connection: close
)
か、要求メッセージを最後まで読んで捨てるべきです >>420。
Expect: 100-continue
を実装することは明示的に要求されているわけではありませんが、
実装しなくても良いとは明記されていません。実装しない場合には
417
を返すべきと思われます。
しかし現実には黙って無視する (要求全体を受信するのを待つ) サーバーもあります。[429] クライアントは、 100-continue
に対して
417
応答を受信した場合、 100-continue
なしで要求を再度行うべきです >>420。
[2] この状態符号は、というかこの仕組みは HTTP/1.0 以前にはなく、 HTTP/1.1 で導入されたものです。 RFC 2068 によればすべての HTTP/1.1 クライアントはとりあえず対応しないといけないことになっていましたが、実装状況を反映して RFC 2616 ではトーンダウンして、対応しているクライアントは Expect: 100-continue
と合図することになっています。
The client
maySHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed. See section 8.2.3 for detailed discussion of the use and handling of this status code.
クライアントは、その要求を続行するべきです。 この暫定応答は、要求の初期部分が受信され、まだサーバーが却下していないことをクライアントに通知するのに使います。 クライアントは、要求の残りの部分を送信することで続行するか、 又は要求が既に完了していればこの応答を無視するかするべきです。 サーバーは、要求が完了する前に最終応答を送信してはなりません。 この状態符号の使用と取扱いについての話題は 8.2.3 節を参照して下さい。
[3] これは RFC 2616 の規定ですが、相当する RFC 2068 の規定 (大分違う。) は持続接続
をご覧下さい。
The purpose of the 100 (Continue) status (see section 10.1.1) is to allow a client that is sending a request message with a request body to determine if the origin server is willing to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body.
100
(継続) 状態の目的は、
要求本体つきの要求メッセージを送信するクライアントが要求本体を送信する前に、
起源サーバーは (要求頭に基づき) 要求を受け入れる意思があるのかを決定することを可能にすることにあります。
場合によっては、サーバーが本体を読まずにメッセージを却下するならクライアントが本体を送信するのは不適切か非常に非効率であるかもしれません。
Requirements for HTTP/1.1 clients:
- If a client will wait for a 100 (Continue) response before sending the request body, it MUST send an Expect request-header field (section 14.20) with the "100-continue" expectation.
- A client MUST NOT send an Expect request-header field (section 14.20) with the "100-continue" expectation if it does not intend to send a request body.
HTTP/1.1 クライアントの要件:
100
(継続)
応答を待つのであれば、 Expect
要求頭欄に
100-continue
期待を入れて送らなければなりません。Expect
要求頭欄に 100-continue
期待を入れて送ってはなりません。Because of the presence of older implementations, the protocol allows ambiguous situations in which a client may send "Expect: 100-continue" without receiving either a 417 (Expectation Failed) status or a 100 (Continue) status. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status, the client SHOULD NOT wait for an indefinite period before sending the request body.
古い実装が存在するために、このプロトコルではクライアントが
Expect: 100-continue
を送信しても
417
(期待失敗) 状態又は 100
(継続)
状態のいずれも受信しない曖昧な状態が存在します。
従って、クライアントがこの頭欄を (串経由であれ) 起源サーバーに送信して一向に
100
(継続) 状態がみられない場合は、
クライアントは要求本体を送る前に無限の時間を待つべきではありません。
Requirements for HTTP/1.1 origin servers:
- Upon receiving a request which includes an Expect request-header field with the "100-continue" expectation, an origin server MUST either respond with 100 (Continue) status and continue to read from the input stream, or respond with a final status code. The origin server MUST NOT wait for the request body before sending the 100 (Continue) response. If it responds with a final status code, it MAY close the transport connection or it MAY continue to read and discard the rest of the request. It MUST NOT perform the requested method if it returns a final status code.
HTTP/1.1 起源サーバーの要件:
Expect
要求頭欄に 100-continue
期待がついたものを含んだ要求を受け取ったときには、
起源サーバーは 100
(継続) 状態で応答して入力流れから読み込みを続行するか、
又は最終状態符号で応答するかしなければなりません。
起源サーバーは、 100
(継続) 応答を送信する前に要求本体を待ってはいけません。
最終状態符号で応答した時は、その転送接続を閉じても構いませんし、
要求の残りを読み込んで捨てても構いません。
最終状態符号を返すのであれば、要求された method を施してはなりません。
- An origin server SHOULD NOT send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue" expectation, and MUST NOT send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility with RFC 2068, a server MAY send a 100 (Continue) status in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header field with the "100-continue" expectation. This exception, the purpose of which is to minimize any client processing delays associated with an undeclared wait for 100 (Continue) status, applies only to HTTP/1.1 requests, and not to requests with any other HTTP-version value.
起源サーバーは、要求メッセージが Expect
要求頭欄で
100-continue
期待を持ったものを含んでいないときには
100
(継続) 応答をするべきではなく、
左様な要求が HTTP/1.0 (以前) のクライアントから来たものであれば
100
(継続) 応答を送ってはなりません。
この規則には例外があります : RFC 2068 との互換性のため、
サーバーは Expect
要求頭欄で 100-continue
期待を持ったものが含まれていなくても HTTP/1.1 の PUT
要求又は POST
要求に対する応答であれば、サーバーは
100
(継続) 状態の応答を送っても構いません。
宣言していない 100
(継続) 状態への待機に関するクライアントの処理の遅延を最小化するためのこの例外は
HTTP/1.1 要求にのみ適用され、他の HTTP-version
値の要求には適用しません。
- An origin server MAY omit a 100 (Continue) response if it has already received some or all of the request body for the corresponding request.
- An origin server that sends a 100 (Continue) response MUST ultimately send a final status code, once the request body is received and processed, unless it terminates the transport connection prematurely.
100
(継続) 応答を省いても構いません。100
(継続) 応答を送信した起源サーバーは、
一度要求を受信して処理したら、転送接続が既に終端していない限り、
最終状態符号を最後に送らなければなりません。
- If an origin server receives a request that does not include an Expect request-header field with the "100-continue" expectation, the request includes a request body, and the server responds with a final status code before reading the entire request body from the transport connection, then the server SHOULD NOT close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise, the client might not reliably receive the response message. However, this requirement is not be construed as preventing a server from defending itself against denial-of-service attacks, or from badly broken client implementations.
起源サーバーが 100-continue
期待を持った
Expect
要求頭欄を含まない要求を受信し、
そしてサーバーが転送接続から要求本体全体を読み込む前に最終状態符号で応答した場合は、
サーバーは要求全体を読み込むか、又はクライアントが転送接続を閉じない限り、
接続を閉じるべきではありません。そうしなければ、
クライアントは確実に応答メッセージを受信できないかもしれません。
しかし、この要件はサーバー自身をサービス拒否攻撃や壊れたクライアント実装から護るためとは解釈出来ません。
Requirements for HTTP/1.1 proxies:
- If a proxy receives a request that includes an Expect request-header field with the "100-continue" expectation, and the proxy either knows that the next-hop server complies with HTTP/1.1 or higher, or does not know the HTTP version of the next-hop server, it MUST forward the request, including the Expect header field.
- If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST respond with a 417 (Expectation Failed) status.
- Proxies SHOULD maintain a cache recording the HTTP version numbers received from recently-referenced next-hop servers.
- A proxy MUST NOT forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an Expect request-header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of 1xx responses (see section 10.1).
HTTP/1.1 串の要件:
Expect
要求頭欄で 100-continue
期待を持ったものを含んだ要求を受け取ったときで、
串が次の hop のサーバーは HTTP/1.1 以上に従っていると知っているか又は次の hop
のサーバーの HTTP の版を知らない時には、その要求を、 Expect
頭欄を含めて転送しなければなりません。417
(期待失敗) 状態で応答しなければなりません。Expect
要求頭欄で 100-continue
期待を持ったものを含んでいなければ、
100
(継続) 応答を転送してはなりません。
この要件は 1xx
要求の転送についての一般規則を上書きします。[442] 100
と 101
の順序については、
Upgrade:
を参照してください。
[449] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( ( 版)) http://tools.ietf.org/html/rfc3507#section-4.3.3
For HTTP, it causes mod_proxy_http to send a 100-Continue to the backend (only valid for HTTP/1.1 - for non HTTP/1.1 backends, this property has no effect).
the Heroku HTTP routers will automatically insert a 100 Continue response on behalf of the application it routes to, and will later forward the data.
[7] Provide opt-in for Expect = "100-continue" · Issue #41 · whatwg/fetch ( ()) https://github.com/whatwg/fetch/issues/41
--expect100-timeout <seconds>
(HTTP) Maximum time in seconds that you allow curl to wait for a 100-continue response when curl emits an Expects: 100-continue header in its request. By default curl will wait one second. This option accepts decimal values! When curl stops waiting, it will continue as if the response has been received.
(Added in 7.47.0)
[9] RFC 8120 - Mutual Authentication Protocol for HTTP () https://tools.ietf.org/html/rfc8120#section-4.5
[11] curl - How To Use (, ) https://curl.haxx.se/docs/manpage.html#--expect100-timeout
[12] FFmpeg Protocols Documentation (, ) https://ffmpeg.org/ffmpeg-protocols.html#http