Transfer-Encoding
Description
The Transfer-Encoding response header specifies the form of encoding used to safely transfer the payload body to the user. This header is primarily used when the size of the response is not known in advance, allowing the server to send the response in chunks rather than as a single block of data.
Unlike Content-Encoding, which relates to the compression of the message content, Transfer-Encoding concerns how the message is packaged for transit between server and client. The most common value for this header is chunked, which enables the server to send parts of the response as they become available, rather than buffering the entire response before sending it.
Transfer encodings are particularly useful for: - Streaming data where the total size is unknown in advance - Generating dynamic content on-the-fly - Improving time-to-first-byte for large responses - Server-sent events and other real-time data feeds
Syntax
The syntax of the Transfer-Encoding header follows this structure:
<encoding>: The encoding format used for the message transfer.- Multiple encodings can be specified, separated by commas, indicating that multiple encodings have been applied in the order listed.
Common Encoding Values
chunked: The message body is transferred in a series of chunks, each with its own size indicator.compress: The message body uses Lempel-Ziv-Welch (LZW) compression (rarely used today).deflate: The message body uses the zlib format with the deflate compression algorithm.gzip: The message body uses the Lempel-Ziv coding (LZ77) with a 32-bit CRC.identity: No encoding is applied (this value is typically not used explicitly).
Example Syntax
This example indicates that the response will be sent in chunks.
Examples
Basic Chunked Encoding Example
A response using chunked transfer encoding:
HTTP/1.1 200 OK
Date: Mon, 02 Jun 2025 21:00:00 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
25
<!DOCTYPE html>
<html>
<head><title>
1A
Chunked Transfer Example
7
</title>
14
</head>
<body><p>Hello,
5
World
9
!</p></body>
8
</html>
0
In this example, the response is broken into chunks. Each chunk starts with the size of the chunk in hexadecimal, followed by the chunk data, and finally a CRLF (carriage return and line feed). The response ends with a chunk of size 0.
Chunked with Trailer Example
A response using chunked encoding with trailing headers:
HTTP/1.1 200 OK
Date: Mon, 02 Jun 2025 21:10:30 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Trailer: X-Checksum, X-Metrics
1B
{"status": "processing",
1C
"progress": "25%",
1A
"estimated_time": 30}
0
X-Checksum: 43b5c9f8e8e707c8f3b14df1f5502dce
X-Metrics: time=235ms;cpu=45%;mem=12MB
In this example, the response includes trailing headers (X-Checksum and X-Metrics) that are sent after the chunked data. The Trailer header in the initial response indicates which headers will be included in the trailer.
Multiple Transfer Encodings Example
A response with multiple transfer encodings:
HTTP/1.1 200 OK
Date: Mon, 02 Jun 2025 21:20:45 GMT
Content-Type: text/plain
Transfer-Encoding: gzip, chunked
[...chunked and gzipped data...]
In this example, the content is first compressed using gzip, then transferred using chunked encoding. The client would need to first decode the chunks, then decompress the resulting data.
Summary
The Transfer-Encoding response header plays a crucial role in HTTP communication by enabling efficient transfer of data when the total size is unknown in advance. Chunked encoding, the most common form, allows servers to start sending responses immediately without needing to buffer the entire content, which improves performance and reduces memory usage on the server. This is particularly valuable for dynamically generated content, streaming data, and large responses. Unlike the Content-Length header, which requires knowing the exact size of the response beforehand, Transfer-Encoding: chunked provides flexibility for servers to generate and transmit content on-the-fly.