Content-Lengthサーバーから[おそらく]大きなファイルを返すために、HTTPヘッダーを設定することと、チャンクエンコーディングを使用することの長所と短所を比較検討しています。永続的な接続を使用して HTTP 1.1 仕様に準拠するには、どちらか一方が必要です。Content-Lengthヘッダーの利点は次のとおりです。
欠点は、オブジェクトを返す前にサイズを計算する必要があることです。これは必ずしも実用的ではなく、サーバー/データベースの使用率を高める可能性があります。チャンク エンコーディングの欠点は、各チャンクとダウンロード プログレス バーの前にチャンク サイズを追加するオーバーヘッドが小さいことです。何かご意見は？私が考えていなかったかもしれない両方の方法のための他の HTTP の考慮事項はありますか?
間違いなくContent-Lengthを使用してください。これによるサーバーの使用率はほとんど存在せず、ユーザーにとってのメリットは大きくなります。
動的コンテンツの場合、圧縮応答サポート（ gzip ）を追加することも非常に簡単です。これには出力バッファリングが必要であり、これによりコンテンツの長さがわかります。（ファイルのダウンロードまたはすでに圧縮されたコンテンツ（サウンド、画像）では実用的ではありません）。
部分的なコンテンツ/バイト範囲の提供、つまりダウンロードを再開する機能のサポートを追加することも検討してください。バイト範囲の例については、ここを参照してください（例はPHPですが、どの言語にも適用できます）。部分的なコンテンツを提供する場合は、Content-Lengthが必要です。
もちろん、これらは特効薬ではありません。ストリーミングメディアの場合、出力バッファリングや応答サイズを使用するのは無意味です。大きなファイルの場合、出力バッファリングは意味がありませんが、Content-Lengthとバイトサービングは非常に意味があります（失敗したダウンロードを再開することは可能です）。
個人的には、知っているときはいつでもContent-Lengthを提供しています。ファイルのダウンロードの場合、ファイルサイズの確認はリソースの観点からは重要ではありません。結果：ユーザーには明確なプログレスバーがあります（gzipのおかげで動的ページのダウンロードが速くなります）。
コンテンツの長さ
ヘッダーは、要求/応答本文のContent-Lengthバイト長を決定します。ヘッダーの指定を怠るとContent-Length、HTTP サーバーは暗黙的にTransfer-Encoding: chunkedヘッダーを追加します。Content-LengthとTransfer-Encodingヘッダーを一緒に使用しないでください。受信者は、本体の長さがわからず、ダウンロードの完了時間を推定できません。ヘッダーを追加する場合はContent-Length、本文全体とバイト単位で一致していることを確認してください。正しくない場合、受信者の動作は未定義です。
ヘッダーはContent-Lengthストリーミングを許可しませんが、部分的なコンテンツ サービングをサポートする必要がある大きなバイナリ ファイルに役立ちます。これは基本的に、再開可能なダウンロード、一時停止されたダウンロード、部分的なダウンロード、およびマルチホーム ダウンロードを意味します。これには、 と呼ばれる追加のヘッダーを使用する必要がありますRange。この手法はバイト サービングと呼ばれます。
転送エンコーディング
を使用するTransfer-Encoding: chunkedことで、単一のリクエストまたはレスポンス内でのストリーミングが可能になります。これは、データがチャンク方式で送信され、コンテンツの表現に影響を与えないことを意味します。
公式には、HTTP クライアントはTE、クライアントが受け入れる転送エンコーディングの種類を指定するヘッダー フィールドを含むリクエストを送信することを意図しています。これは常に送信されるわけではありませんが、ほとんどのサーバーは、クライアントがchunkedエンコーディングを処理できると想定しています。
chunked転送エンコーディングは、HTTP 1.1 がデフォルトで true であると想定している永続的な TCP 接続をより有効に利用します 。
コンテンツ エンコーディング
チャンク化されたデータまたはチャンク化されていないデータを圧縮することもできます。これは実際にはContent-Encodingヘッダーを介して行われます。
Content-Lengthは、 の後の本体の長さに等しいことに注意してくださいContent-Encoding。これは、応答を gzip した場合、圧縮後に長さの計算が行われることを意味します。長さを計算する場合は、本体全体をメモリにロードできる必要があります (その情報が他にない場合)。
チャンク エンコーディングを使用してストリーミングする場合、圧縮アルゴリズムはオンライン処理もサポートする必要があります。ありがたいことに、gzip はストリーム圧縮をサポートしています。コンテンツは最初に圧縮されてから、チャンクに分割されると思います。このようにして、チャンクが受信され、解凍されて実際のコンテンツが取得されます。逆の場合は、圧縮されたストリームを取得し、解凍するとチャンクが得られます。これは意味がありません。
一般的な圧縮ストリーム応答には、次のヘッダーが含まれる場合があります。
Content-Type: text/html
Content-Encoding: gzip
Transfer-Encoding: chunked
意味的には、 の使用はContent-Encoding「エンド ツー エンド」エンコーディング スキームを示します。これは、最終クライアントまたは最終サーバーのみがコンテンツをデコードすることになっていることを意味します。中間のプロキシは、コンテンツをデコードすることを想定していません。
中間のプロキシがコンテンツをデコードできるようにする場合、使用する正しいヘッダーは実際にはTransfer-Encodingヘッダーです。HTTP リクエストがTE: gzip chunkedヘッダーを持っていた場合、 で応答することは正当Transfer-Encoding: gzip chunkedです。
ただし、これがサポートされることはほとんどありません。Content-Encodingしたがって、今は圧縮にのみ使用する必要があります。