HTTPプロトコルでのContent-Lengthの解釈

HTTPプロトコルでは、Content-Lengthの詳細な解釈があります。 Content-Lengthは、HTTPメッセージエンティティの転送長を表すために使用されます。 ＨＴＴＰプロトコルでは、メッセージ実体の長さとメッセージ実体の送信長とが異なり、例えば、ｇｚｉｐ圧縮では、メッセージ実体の長さは圧縮前の長さであり、メッセージ実体の送信長はｇｚｉｐ圧縮後の長さである。特定のHTTP対話では、主に次の規則に基づいて、クライアントはメッセージ長を取得します。応答が1xx、204、304、またはhead要求の場合、メッセージエンティティの内容は直接無視されます。 Transfer-Encodingがある場合は、まずTransfer-Encodingのメソッドを使用して対応する長さを見つけます。たとえば、チャンクモードです。 - 先頭にContent-Lengthがある場合、このContent-Lengthはエンティティの長さと転送の長さの両方を表します。エンティティの長さと転送の長さが等しくない場合（たとえば、Transfer-Encodingが設定されている場合）、Content-Lengthは設定できません。 Transfer-Encodingが設定されている場合、Content-Lengthは無視されます。この文章翻訳の利点は、実際のところ、重要な点は以下のとおりです。Transfer-Encodingでは、Content-Lengthを使用できません。レンジ伝送注意を払ってはいけない、詳細に読んでいない：）接続の長さは、サーバーを介して接続を閉じることによって決定することができます。 （要求側は接続を閉じることによって要求メッセージ本体の終わりを示すことはできません。これはサーバーに応答を続ける機会を与えないからです）。この状況は主に短い接続、つまり非キープアライブモードに対応します。 HTTP 1.1はチャンクモードをサポートしなければなりません。メッセージの長さが不明確な場合、これはチャンクメカニズムによって処理できるためです。メッセージの内容を含むヘッダーに、content-lengthフィールドがある場合、そのフィールドに対応する値はメッセージの件名の長さと一致しなければなりません。 「メッセージの実体長は、転送符号化が適用される前のメッセージ本体の長さである」、つまりチャンクの内容長はない。

実際には、以下の記事はほとんど無視できますが、要約すると次のようになります：1. Content-Lengthが存在し有効である場合、それはメッセージコンテンツの伝送長と正確に同じでなければなりません。 （テスト後、短すぎると切り捨てられます。長すぎるとタイムアウトの原因となります。）2. Transfer-Encodingがある（フォーカスが集中している）場合は、ヘッダーにContent-Lengthがないため無視されます。 3.短い接続が使用されている場合、メッセージの接続長はサーバーが接続を閉じることによって直接決定できます。 （これは理解しやすいです）Http1.1がキープアライブをサポートしていない前など、HTTPプロトコルの他の機能と組み合わせること。それから、次の結論を引き出すことができます。1. Http 1.0以前のバージョンでは、content-lengthフィールドはオプションです。 2. http 1.1以降のバージョン。キープアライブなら、content-lengthとchunkは2でなければなりません。生きていない場合は、http1.0と同じです。内容の長さはオプションです。