Trailer
The HTTP Trailer request and response header announces which fields the sender will append after the final chunk in a chunked Transfer-Encoding message.
Usage
The Trailer header announces which header fields appear after the final chunk in a chunked Transfer-Encoding message. Trailer fields carry metadata the sender cannot determine until the entire body has been transmitted, such as message integrity checksums, digital signatures, or post-processing status indicators.
A sender includes the Trailer header in the
message head to give the recipient advance notice of
which fields to expect. A client sending
TE: trailers declares willingness to accept
trailer fields, and a server is free to omit
trailers for clients giving no such signal.
Trailer fields are useful in Streaming scenarios where the server generates the response body incrementally. A checksum over the entire body, for example, is only available after the last byte has been written.
Trailer consumption happens mostly server-to-server.
Among browsers, Firefox surfaces a
Server-Timing trailer in DevTools,
and the fetch() and XMLHttpRequest APIs expose
header fields from the message head only.
Restrictions
Several categories of header fields are prohibited from appearing as trailers:
- Message framing headers such as Transfer-Encoding and Content-Length
- Routing headers such as Host
- Authentication headers such as Authorization and Set-Cookie
- Request modifier headers such as Max-Forwards
- Response controls such as Cache-Control
- Content format headers such as Content-Encoding, Content-Type, Content-Range, and Trailer itself
These restrictions exist because intermediaries and clients need these headers before processing the body.
Example
A server sends a chunked response with a trailer
field. The Trailer header in the message head
announces the Server-Timing field will follow the
body, carrying timing metrics computed after the
full response has been generated.
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
Trailer: Server-Timing
7\r\n
Mozilla\r\n
9\r\n
Developer\r\n
0\r\n
Server-Timing: total;dur=135.7\r\n
\r\n
Multiple trailer fields are listed as a comma-separated value. This response announces both a timing field and a digest field in the trailer section.
Trailer: Server-Timing, Content-Digest
Support in practice
Trailer delivery depends on the protocol version. HTTP/1.1 carries trailer fields after the final zero-length chunk of a chunked message, so chunked Transfer-Encoding is a precondition. HTTP/2 and HTTP/3 drop chunked encoding entirely and carry trailers as a second HEADERS frame following the data, which makes the mechanism cleaner and independent of the Trailer announcement.
gRPC over HTTP/2 is the largest real-world consumer.
The grpc-status and grpc-message fields arrive as
trailers, because the outcome of a streaming call is
known only once the stream ends. A proxy discarding
trailers breaks gRPC calls while ordinary requests
continue working, which makes the failure look
protocol-specific rather than infrastructural.
Intermediaries are the usual reason trailers go
missing. Reverse proxies and CDNs frequently drop
trailer fields while forwarding the body intact, and
buffering proxies discard them when assembling a
complete response before sending. Sending a request
without TE: trailers also entitles a server
to omit them.
The gap between generating trailers and observing
them causes most of the confusion. Browser APIs
expose the message head only, so a trailer arriving
correctly on the wire stays invisible to fetch()
and XMLHttpRequest. Confirming delivery calls for
a protocol-level capture rather than developer tools.
