TETE tells the server which transfer codings the client will accept in the response, and whether it will accept trailers. Think of it as the 'transfer (hop-by-hop)' analog of Accept-Encoding.
Values include transfer compressions like `gzip`/`deflate` and the special token `trailers` (willingness to accept trailer headers), e.g. `TE: trailers, gzip`.
The key is the distinction between end-to-end content coding (Content-Encoding/Accept-Encoding) and hop-by-hop transfer coding (Transfer-Encoding/TE). Content-Encoding compresses the resource representation itself and is preserved end-to-end, whereas Transfer-Encoding is a transfer mechanism between two adjacent nodes and can change per hop. TE expresses the client's capability for the latter.
The most practical value is `trailers`. When streaming a body with Transfer-Encoding: chunked, the server can append information computable only after the body (integrity digest, signature, processing status) as trailing headers, but the client must announce `TE: trailers` for the server to send them, along with a Trailer header.
TE is a hop-by-hop header, so per spec it is listed in the Connection header and consumed per connection rather than forwarded. In HTTP/2 and HTTP/3 the transport handles framing and compression itself, so `chunked`/`gzip` transfer codings disappear, and TE effectively carries only `trailers` (other values are forbidden).
TE: <transfer-coding>[;q=<weight>][, ...]e.g. TE: trailers, gzip
trailers | Signals willingness to accept trailer (trailing) headers after chunked transfer; a special valueless token. |
gzip | Accepts gzip as a hop-by-hop transfer compression, distinct from Accept-Encoding (end-to-end). |
chunked | Chunked transfer coding; always supported in HTTP/1.1, so it need not be listed. |
q=<0.0~1.0> | Preference weight for each transfer coding. |