Transfer-Encoding header
Baseline Widely available
This feature is well established and works across many devices and browser versions. It’s been available across browsers since July 2015.
The HTTPTransfer-Encodingrequest andresponse header specifies the form of encoding used to transfer messages between nodes on the network.
Transfer-Encoding is ahop-by-hop header, that is applied to a message between two nodes, not to a resource itself.Each segment of a multi-node connection can use differentTransfer-Encoding values.If you want to compress data over the whole connection, use the end-to-endContent-Encoding header instead.
In practice this header is rarely used, and in those cases it is almost always used withchunked.
That said, the specification indicates that when present in a message it indicates the compression used on the message in that hop, and/or whether the message has been chunked.For example,Transfer-Encoding: gzip, chunked indicates that the content has been compressed using the gzip coding and then chunked using the chunked coding while forming the message body.
The header is optional in responses to aHEAD request as these messages have no body and, therefore, no transfer encoding.When present it indicates the value that would have applied to the corresponding response to aGET message, if thatGET request did not include a preferredTransfer-Encoding.
Warning:HTTP/2 disallows all uses of theTransfer-Encoding header.HTTP/2 and later provide more efficient mechanisms for data streaming than chunked transfer.Usage of the header in HTTP/2 may likely result in a specificprotocol error.
In this article
Syntax
Transfer-Encoding: chunkedTransfer-Encoding: compressTransfer-Encoding: deflateTransfer-Encoding: gzip// Several values can be listed, separated by a commaTransfer-Encoding: gzip, chunkedDirectives
chunkedData is sent in a series of chunks.Content can be sent in streams of unknown size to be transferred as a sequence of length-delimited buffers, so the sender can keep a connection open, and let the recipient know when it has received the entire message.The
Content-Lengthheader must be omitted, and at the beginning of each chunk, a string of hex digits indicate the size of the chunk-data in octets, followed by\r\nand then the chunk itself, followed by another\r\n.The terminating chunk is a zero-length chunk.compressA format using theLempel-Ziv-Welch (LZW) algorithm.The value name was taken from the UNIXcompress program, which implemented this algorithm.Like the compress program, which has disappeared from most UNIX distributions, this content-encoding is used by almost no browsers today, partly because of a patent issue (which expired in 2003).
deflateUsing thezlib structure (defined inRFC 1950), with thedeflate compression algorithm (defined inRFC 1951).
gzipA format using theLempel-Ziv coding (LZ77), with a 32-bit CRC.This is originally the format of the UNIXgzip program.The HTTP/1.1 standard also recommends that the servers supporting this content-encoding should recognize
x-gzipas an alias, for compatibility purposes.
Examples
>Response with chunked encoding
Chunked encoding is useful when larger amounts of data are sent to the client and the total size of the response may not be known until the request has been fully processed.For example, when generating a large HTML table resulting from a database query or when transmitting large images.A chunked response looks like this:
HTTP/1.1 200 OKContent-Type: text/plainTransfer-Encoding: chunked7\r\nWelcome\r\n1c\r\nto Mozilla Developer Network\r\n0\r\n\r\nSpecifications
| Specification |
|---|
| HTTP/1.1> # field.transfer-encoding> |