[1] メッセージの長さとして指定されているものより実際の長さが短い場合、 そのメッセージは不完全であるといいます。
[12] chunked 転送符号化を使っているメッセージ本体は、
長さ0の最後の chunk を受信していなければ不完全です >>49。
そうでないとき完全です >>2。
[3] chunked の復号に失敗した時も不完全なメッセージとして扱うようです
>>49。
[6] 妥当な Content-Length: を持つメッセージは、
メッセージ本体として受信したオクテットの長さが
Content-Length: の長さより小さい時、
不完全です >>49。そうでない時完全です >>2。
[16] chunked でなく Content-Length:
もない応答メッセージは、ヘッダー部を受信していれば、
HTTP接続が閉じられるまでがメッセージ本体です >>49。
不完全なことはありません。
[17] 要求メッセージは chunked でなく
Content-Length: もなければ、
メッセージ本体の長さが0ですから、不完全なことはありません。
[14] なおヘッダー部と空行までの途中で終わっている場合、 「不完全」とはされていませんが、クライアントは応答の意味を決定できないので要求を繰り返す必要があるかもしれない >>49 とされています。鯖もおそらく同様で要求をエラーとして無視するべきなのでしょう。
[50] 不完全な要求を受け取った鯖は、 接続を閉じる前に誤り応答を送信して構いません >>49。
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。
[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>
Transfer-Encoding:とContent-Length:の両方がある時はContent-Length:が無視されるので (メッセージ本体参照。)、 >>12 が適用されます。