100

状態符号 100 (HTTP)

[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

文脈

[438] HTTP/1.0 クライアント100 を含む 1xx 応答を送ってはなりません

処理

[439] HTTP/1.1 クライアント100 を含む 1xx 応答構文解析を実装しなければなりません

[446] クライアントは、要求Expect: 100-continue を含めなかった場合、 100 応答を捨てて構いません >>443

含めていた場合については >>424 参照。

[440] は自身が 100 を含む 1xx 応答を要求した場合を除き、これを転送しなければなりません。 自身が要求100要求を追加して転送した場合は、 100転送する必要はありません。

[6] HTTP/1.0 応答100 応答だった時どう処理するべきかは不明です。

100-continue

[424] Expect: ヘッダーの値 100-continue は、クライアントが (おそらく大きな) メッセージ本体を当該要求メッセージ本体で送信しようとしており、 要求行ヘッダーのみから即座に成功、リダイレクト、エラーのいずれかの応答を返すことができなければ 100 応答を受信したいと望んでいることを、 受信者に通知するものとなっています >>420

[425] これによりクライアントメッセージ本体を送信する前に送信する意味があるか判断できますから、 メッセージ本体が大きい時やエラーになりそうな時に効率を向上させることができます >>420

C
クライアント
S
C -> S
ヘッダー (Expect: 100-continue)
S -> C
100 応答
C -> S
メッセージ本体
S -> C
最後の応答

[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-continueUpgrade: が共に指定されているときは、まず 100 を送り、次に 101 を送ります >>421

[432] は、 100 を送った場合、 メッセージ本体を受信して処理したら、 (接続が途中で閉じられた場合を除き、) 最終的な状態符号応答を送信しなければなりません >>420

[433] は、メッセージ本体をすべて読む前に最終的な状態符号応答を送信する場合、 接続を閉じることを応答に示す (Connection: close) か、要求メッセージを最後まで読んで捨てるべきです >>420

[448] Expect: 100-continue を実装することは明示的に要求されているわけではありませんが、 実装しなくても良いとは明記されていません。実装しない場合には 417 を返すべきと思われます。 しかし現実には黙って無視する (要求全体を受信するのを待つ) サーバーもあります。

[429] クライアントは、 100-continue に対して 417 応答を受信した場合、 100-continue なしで要求を再度行うべきです >>420

[10] が、HTTPクライアントライブラリーの実装によっては、 100-continue を指定して 417 を受け取ったらそのままアプリケーションに渡すものもあります。 これでは 417 を返すサーバーから意味のある応答を受け取ることができないので、 Web互換ではありません。汎用ライブラリーはそもそも Expect: を指定するべきではありません。

歴史

[2] この状態符号は、というかこの仕組みは HTTP/1.0 以前にはなく、 HTTP/1.1 で導入されたものです。 RFC 2068 によればすべての HTTP/1.1 クライアントはとりあえず対応しないといけないことになっていましたが、実装状況を反映して RFC 2616 ではトーンダウンして、対応しているクライアントは Expect: 100-continue と合図することになっています。

HTTP/1.1

[418] RFC 2068・2616 (HTTP/1.1) 10.1.1 100 Continue

The client may SHOULD 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 の規定 (大分違う。) は持続接続をご覧下さい。

[419] RFC 2616 (HTTP/1.1) 8.2.3 Use of the 100 (Continue) Status

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 頭欄を含めて転送しなければなりません
  • 串が次の hop のサーバーの版が HTTP/1.0 以下であると知っている時には、 その要求を転送してはならず417 (期待失敗) 状態で応答しなければなりません
  • 串は、以前に参照した次の hop のサーバーから受取った HTTP の版を記録したキャッシュを維持するべきです。 串は、要求メッセージが HTTP/1.0 (以前) のクライアントから受信したものであって、 Expect 要求頭欄で 100-continue 期待を持ったものを含んでいなければ、 100 (継続) 応答を転送してはなりません。 この要件は 1xx 要求の転送についての一般規則を上書きします。

実装

関連

[442] 100101 の順序については、 Upgrade: を参照してください。

[449] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( ( 版)) http://tools.ietf.org/html/rfc3507#section-4.3.3

[4] mod_proxy - Apache HTTP Server Version 2.4 ( 版) http://httpd.apache.org/docs/current/en/mod/mod_proxy.html#ProxyPass

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).

[5] HTTP Routing | Heroku Dev Center ( 版) https://devcenter.heroku.com/articles/http-routing

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

[8] cURL - How To Use ( ()) https://curl.haxx.se/docs/manpage.html#--expect100-timeout

--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