Http プロトコル_html/css_WEB-ITnose の Content-Length の解釈

HTTP プロトコルには、Content-Length の詳細な説明があります。 Content-Length は、HTTP メッセージ エンティティのメッセージ本文の転送長を記述するために使用されます。 HTTP プロトコルでは、メッセージ エンティティの長さとメッセージ エンティティの送信長には違いがあります。たとえば、gzip 圧縮では、メッセージ エンティティの長さは圧縮前の長さであり、メッセージ エンティティの送信長は圧縮後の長さになります。 gzip圧縮後の長さ。

特定の HTTP インタラクションにおいて、クライアントがメッセージ長を取得する方法は主に次のルールに基づいています:

応答が 1xx、204、304 またはヘッドリクエストの場合、メッセージエンティティの内容は直接無視されます。

Transfer-Encoding がある場合、最初に Transfer-Encoding のメソッドが使用され、対応する長さが検索されます。たとえば、チャンクモード。

「先頭にContent-Lengthがある場合、このContent-Lengthはエンティティ長と転送長の両方を表します。エンティティ長と転送長が等しくない場合（例えば、Transfer-Encodingが設定されている場合）、 Content-Length を長さに設定することはできません。Transfer-Encoding が設定されている場合、Content-Length は無視されます。」この文を翻訳する利点は実際に重要です。Transfer-Encoding では、Content-Length は存在できません。

範囲送信。フォローしないでください、詳しく読んでいません:)

メッセージの送信長は、サーバー経由の接続を閉じることで決定できます。 (リクエスタは、接続を閉じることでリクエスト メッセージ本文の終わりを示すことはできません。これは、サーバーが応答を続ける機会を拒否することになるためです)。この状況は主に短い接続、つまり非キープアライブ モードに対応します。

HTTP1.1はチャンクモードをサポートする必要があります。メッセージの長さが不確実な場合、チャンク メカニズムを使用してこの状況に対処できるためです。

メッセージの内容を含むヘッダーに content-length フィールドがある場合、このフィールドに対応する値はメッセージの件名の長さと完全に一致する必要があります。

「メッセージのエンティティ長は、転送コーディングが適用される前のメッセージ本文の長さです。」

つまり、チャンクが存在する場合、コンテンツ長は存在できません。

実際、次のいくつかの項目はほとんど無視できます。簡単にまとめると次のとおりです:

1. Content-Length が存在し、有効である場合、メッセージコンテンツの送信長と完全に一致する必要があります。 (テスト後、短すぎる場合は切り詰められ、長すぎる場合はタイムアウトが発生します。)

2. Transfer-Encodingがある(フォーカスがチャンクされている)場合、Contentはありません。 -ヘッダーの長さ。無視されます。

3. 短い接続が使用されている場合、メッセージの送信長は、サーバーを介して接続を閉じることによって直接決定できます。 (これはわかりやすいです)

HTTPプロトコルの他の機能と組み合わせると、例えば以前のHTTP1.1はキープアライブをサポートしていません。そして、次の結論を導き出すことができます:

1. HTTP 1.0 以前のバージョンでは、content-length フィールドは不要です。

2. http1.1 以降のバージョン。キープアライブの場合、content-length と chunk は 2 つのうちのいずれかである必要があります。キープアライブしない場合はhttp1.0と同じです。 content-length はオプションです。