Transfer-Encoding ヘッダーは、ネットワーク上のノード間でメッセージを転送する際に使用するエンコード方式を指定します。

Transfer-Encoding はホップバイホップヘッダーであり、リソース自体ではなく、二つのノード間のメッセージに適用されます。ノード間のコネクションが複数ある場合は、それぞれの区間で使用するTransfer-Encoding の値が異なることがあります。コネクション全体を通してデータを圧縮したい場合は、代わりにエンドトゥエンドのContent-Encoding ヘッダーを使用してください。

本文のないHEAD リクエストに対するレスポンスで使われたときは、対応するGET メッセージに適用されるであろう値を示します。

構文

Transfer-Encoding: chunkedTransfer-Encoding: compressTransfer-Encoding: deflateTransfer-Encoding: gzip// カンマで区切って複数の値を並べることができますTransfer-Encoding: gzip, chunked

ディレクティブ

chunked

データはチャンク（塊）の連続で送られます。この場合はContent-Length ヘッダーが省略されます。それぞれのチャンクの先頭に現在のチャンクの長さを 16 進数の形式で追加し、その後で\r\n が続き、チャンク自体ももう一つの\r\n が続きます。最後のチャンクは通常のチャンクですが、長さが 0 であるという点が異なります。この後に、一連のエンティティのヘッダーフィールド（おそらく空）から成るトレイラーが続きます。

compress

Lempel-Ziv-Welch (LZW) アルゴリズムを使用した形式です。この値の名前はこのアルゴリズムを実装している UNIX のcompress プログラムから採られました。特許問題（2003 年に期限切れ）の影響もあり、多くの UNIX ディストリビューションから compress プログラムが消滅したように、今日ではこのコンテンツ符号化方式を使用しているブラウザーはほとんどありません。

deflate

zlib 構造体（RFC 1950 で定義）とdeflate 圧縮アルゴリズム（RFC 1951 で定義）を使用します。

gzip

Lempel-Ziv coding (LZ77) と 32 ビット CRC を使用する形式です。これは元は UNIX のgzip プログラムの形式です。HTTP/1.1 標準は、互換性のために、このコンテンツ符号化方式の別名としてx-gzip を解釈することにサーバーが対応することを推奨しています。

例

チャンク化の符号化

チャンク化の符号化は、大量のデータをクライアントに送り、リクエストが完了するまでレスポンスの合計の長さが分からない場合に便利です。例えば、巨大な HTML の表をデータベースのクエリーの結果として作成したり、大きな画像を転送したりする場合などです。チャンク化されたレスポンスは以下のようになります。

HTTP/1.1 200 OKContent-Type: text/plainTransfer-Encoding: chunked7\r\nMozilla\r\n11\r\nDeveloper Network\r\n0\r\n\r\n

仕様書

ブラウザーの互換性

関連情報

• Accept-Encoding
• Content-Encoding
• Content-Length
• トレイラーの使用を制御するヘッダーフィールド:TE (リクエスト) およびTrailer (レスポンス)
• チャンク化された転送エンコーディング