Transfer-Encoding

Transfer-Encoding ヘッダーは、ペイロード本文をユーザーに安全に転送するために使われる符号化方式を指定します。

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

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

Transfer-Encoding: chunked
Transfer-Encoding: compress
Transfer-Encoding: deflate
Transfer-Encoding: gzip
Transfer-Encoding: identity

// コンマで区切って複数の値を並べることができます
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 を解釈することにサーバーが対応することを推奨しています。

identity

恒等写像 (つまり、圧縮なし、変更なし) であることを示します。このトークンは、特に明示された場合は、常に受け付けられるとみなされます。

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

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
7\r\n
Network\r\n
0\r\n
\r\n

このページの互換性一覧表は構造化データから生成されています。データに協力していただけるのであれば、 https://github.com/mdn/browser-compat-data をチェックアウトしてプルリクエストを送信してください。

• Accept-Encoding
• Content-Encoding
• Content-Length
• トレイラーの使用を制御するヘッダーフィールド: TE (リクエスト) および Trailer (レスポンス)

• チャンク化された転送エンコーディング