Transfer-Encoding
The HTTP Transfer-Encoding request and response header specifies the encoding applied to the message body for safe transfer between nodes.
Usage
The Transfer-Encoding header is a hop-by-hop header describing how the message body is encoded for the current connection segment. Each intermediary (proxy, gateway) decodes the transfer encoding, processes the message, and re-encodes before forwarding to the next node.
The most common value is chunked, which allows a
server to start sending a response before knowing the
total Content-Length. The server
breaks the body into chunks, each prefixed with a
size indicator. A zero-length chunk signals the end of
the message.
Unlike Content-Encoding, which applies end-to-end compression to the resource itself, Transfer-Encoding operates only between two adjacent nodes. A server sending a gzip-compressed resource over a chunked connection uses Content-Encoding for the compression and Transfer-Encoding for the chunking.
When Transfer-Encoding appears in a response to an HTTP HEAD request, the value reflects the encoding the server applies to the body in a corresponding GET response.
Note
The Transfer-Encoding header is forbidden in HTTP/2 and HTTP/3. These protocols provide their own data framing mechanisms, making transfer-level encoding unnecessary.
Directives
chunked
The chunked directive splits the message body into
a series of chunks. Each chunk starts with the chunk
size in hexadecimal, followed by the chunk data. A
final chunk of size zero terminates the message. The
Trailer header lists any fields appended
after the last chunk.
compress
The compress directive applies Lempel-Ziv-Welch
(LZW) compression. This encoding is rarely used in
modern deployments.
deflate
The deflate directive applies zlib compression
with the deflate algorithm.
gzip
The gzip directive applies Lempel-Ziv coding (LZ77)
with a 32-bit CRC checksum. This is the same
algorithm used by the gzip file format and is widely
supported across HTTP implementations.
Example
A server sends a chunked response. The absence of a Content-Length header indicates the server is streaming the body in pieces.
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
Multiple transfer encodings are applied in order. In this response, the body is first gzip-compressed and then chunked for transmission.
Transfer-Encoding: gzip, chunked
Takeaway
The Transfer-Encoding header describes the
hop-by-hop encoding applied to the message body
during transit. The chunked value enables streaming
responses without a predetermined
Content-Length.
