Transfer-Encoding

使い方

Transfer-Encoding ヘッダーはホップバイホップのヘッダーで、現在の接続区間でメッセージボディがどのようにエンコードされているかを記述します。各中間装置（プロキシ、ゲートウェイ）は転送エンコーディングをデコードし、メッセージを処理してから、次のノードへ転送する前に再エンコードします。

最も一般的な値は chunked で、これによりサーバーは Content-Length の総量を知る前にレスポンスのストリーミングを開始できます。サーバーはボディをチャンクに分割し、各チャンクの先頭にサイズの表示を付けます。長さ 0 のチャンクがメッセージの終わりを示します。

リソースそのものにエンドツーエンドの圧縮を適用する Content-Encoding とは異なり、Transfer-Encoding は隣接する 2 つのノードの間でのみ機能します。chunked 接続上で gzip 圧縮したリソースを送るサーバーは、圧縮に Content-Encoding を、チャンク化に Transfer-Encoding を使います。

HTTP の HEAD リクエストへのレスポンスに Transfer-Encoding が現れる場合、その値は対応する GET レスポンスでサーバーがボディに適用するエンコーディングを反映します。

注意

Content-Encoding はエンドツーエンドです。リソースそのものが圧縮され（例: gzip）、すべての受信者がペイロードをデコードします。Transfer-Encoding はホップバイホップです。隣接する 2 つのノード間の転送のために適用され、各ホップで取り除かれます。1 つのレスポンスが両方のヘッダーを同時に持つこともあり、その場合はリソースの圧縮に Content-Encoding を、chunked での配信に Transfer-Encoding を使います。

注意

HTTP の Transfer-Encoding ヘッダーは、メールの Content-Transfer-Encoding とは無関係です。後者はメール本文に対する base64 や quoted-printable といった MIME エンコーディングを扱います。

注意

Transfer-Encoding ヘッダーは HTTP/2 と HTTP/3 では禁止されています。これらのプロトコルは独自のデータフレーミングの仕組みを備えているため、転送レベルのエンコーディングは不要です。

chunked

chunked ディレクティブは、メッセージボディを一連のチャンクに分割します。各チャンクは 16 進数のチャンクサイズで始まり、その後にチャンクデータが続きます。サイズ 0 の最終チャンクがメッセージを終了させます。Trailer ヘッダーは、最後のチャンクの後に付加されるフィールドを列挙します。

compress

compress ディレクティブは Lempel-Ziv-Welch（LZW）圧縮を適用します。このエンコーディングは現代の運用ではほとんど使われません。

deflate

deflate ディレクティブは deflate アルゴリズムによる zlib 圧縮を適用します。

gzip

gzip ディレクティブは 32 ビット CRC チェックサム付きの Lempel-Ziv 符号化（LZ77）を適用します。これは gzip ファイル形式で使われるものと同じアルゴリズムで、HTTP の実装全般で広くサポートされています。

例

サーバーが chunked のレスポンスを送ります。Content-Length ヘッダーがないことは、サーバーがボディを小分けにしてストリーミングしていることを示します。

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

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

複数の転送エンコーディングは順番に適用されます。このレスポンスでは、ボディはまず gzip で圧縮され、その後に送信のためチャンク化されています。

Transfer-Encoding: gzip, chunked