6.3. メッセージボディの長さ（RFC 9112 sec6.3.）

httpメッセージの長さは、次に示す優先順位で決定される。 （webservに含まれない実装範囲は除外）

1. 204（コンテンツなし）ステータスコードを含む応答は、ヘッダーフィールドの後に最初の空の行によって常に終了。 bodyまたはトレーラーセクションを含めることはできません。

2. Transfer-EncodingとContent-Lengthヘッダーフィールドの両方を含むメッセージが受信された場合、Transfer-EncodingはContent-Lengthを上書きします。このようなメッセージは、要求の密輸（セクション11.2）または応答分割（セクション11.1）を実行する試みを示している可能性があり、エラーとして処理する必要があります。（ここの～する必要があるはRFC的に強制力のある表現ではないが400で接続閉じるが適切？）

3. Transfer-Encodingヘッダーフィールドが存在し、chunkedが最終エンコーディングである場合、bodyの長さは、Transfer-Encodingがデータが完了することを示すまで、チャンクデータを読み取り、デコードすることによって決定されます。 Transfer-Encodingヘッダーフィールドがリクエストに存在し、chunkedが最終エンコードではない場合、bodyの長さを確実に決定することはできません。サーバーは、400ステータスコードで応答し、接続を閉じる必要があります。

4. Transfer-Encodingなし、不正なContent-Lengthのメッセージが受信されたとき、受信者は回復不可能なエラーとして扱い400で応答接続を閉じる。ただし、Content-Lengthのフィールド値をカンマ区切りのリストとして正常に解析でき、リスト内の値がすべて有効で同じ値のときを場合を除く。

5. 有効なContent-LengthヘッダーフィールドがTransfer-Encodingなしで存在する場合、その10進数値はオクテットの予想されるメッセージボディの長さを定義します。指定されたbyte数を受信する前に、送信者が接続を閉じるか、タイムアウトした場合、受信者はメッセージが不完全であるとみなして、接続を閉じる必要がある。

6. これがリクエストメッセージであり、上記のいずれにも該当しない場合、メッセージボディの長さはゼロ（メッセージ本文は存在しない）

~~　優先順位はここまで　~~

カンマ区切りのContent-Lengthフィールドについて

RFC 9110 sec8.6より

ABNFは Content-Length = 1*DIGIT
文法的にはカンマ区切りのContent-Lengthフィールドではない。 が例外として、Content-Length: 42, 42のような同値のカンマ区切りで表現される場合は単一の10進数として扱うことが出来る。 分離された複数のContent-Lengthフィールドはエラー、カンマ区切りで送信される同値の10進数はバリデーションしてもいい。