incomplete

不完全メッセージ (HTTP)

[1] メッセージの長さとして指定されているものより実際の長さが短い場合、 そのメッセージ不完全 (incomplete) であるといいます。

仕様書

定義

[12] chunked 転送符号化を使っているメッセージ本体は、 長さ0の最後の chunk を受信していなければ不完全です >>49。 そうでないとき完全です >>2

[13] トレーラー部を受信していなくても不完全ではないことになります。

[3] chunked復号に失敗した時も不完全メッセージとして扱うようです >>49

[6] 妥当Content-Length: を持つメッセージは、 メッセージ本体として受信したオクテットの長さが Content-Length: の長さより小さい時、 不完全です >>49。そうでない時完全です >>2

[15] Transfer-Encoding:Content-Length: の両方がある時は Content-Length: が無視されるので (メッセージ本体参照。)、 >>12 が適用されます。

[16] chunked でなく Content-Length: もない応答メッセージは、ヘッダー部を受信していれば、 HTTP接続が閉じられるまでがメッセージ本体です >>49不完全なことはありません。

[17] 要求メッセージchunked でなく Content-Length: もなければ、 メッセージ本体の長さが0ですから、不完全なことはありません。

[14] なおヘッダー部空行までの途中で終わっている場合、 「不完全」とはされていませんが、クライアント応答の意味を決定できないので要求を繰り返す必要があるかもしれない >>49 とされています。もおそらく同様で要求をエラーとして無視するべきなのでしょう。

処理

[50] 不完全要求を受け取ったは、 接続を閉じる前に誤り応答を送信して構いません >>49

[4] 400 応答を送るべきと思われます。
[5] chunked 符号化が長さ0の chunk を含まない場合、最後の chunk なしで接続が閉じられたか、 構文的に chunk でないデータが続いている場合です。 後者の場合の処理は仕様上明確にされていませんが、実際上は (400 応答を送りたければ送って) 接続を閉じる以外に選択肢がなさそうです。

[51] 不完全応答を受け取ったクライアントは、 当該メッセージ不完全と記録しなければなりません >>49

[7] 不完全応答状態符号200ヘッダー部全体を受信していて、要求メソッドGET だった場合は、キャッシュ項目を不完全と記しつつ蓄積しても構いません >>2

[55] >>6 の場合、接続は閉じなければなりません >>30 3.3.3.

[8] キャッシュは、 Range:Content-Range:範囲単位に対応している場合、不完全応答206 応答蓄積して構いません。また不完全200 応答206 応答として蓄積して構いません。 >>2

[9] キャッシュは、不完全応答の後範囲要求の結果を結合して完全な応答を作っても構いません >>2

[10] キャッシュは、完全にした場合や範囲要求範囲が収まっている場合を除き、 不完全応答を再利用してはなりません >>2

[11] HTTPS範囲要求も参照。

[18] Fetch abort & no-cors requests · Issue #563 · whatwg/fetch () <https://github.com/whatwg/fetch/issues/563#issuecomment-314082009>

[19] Fetch abort & no-cors requests · Issue #563 · whatwg/fetch () <https://github.com/whatwg/fetch/issues/563>