TrailerTrailer announces, ahead of time, the names of trailing headers (trailers) that will follow the body in chunked transfer (Transfer-Encoding: chunked). The recipient uses this list to expect and process trailers at the end of the body.
The value is a list of header names to be sent as trailers (e.g. `Trailer: Expires, Content-Digest`); the actual trailer values arrive at the end of the chunked stream.
Trailers exist to handle headers whose value is known only after the whole body is produced. While streaming a response, you can append values unknown at the start (an integrity hash over the full body, a signature, a final processing status) as trailers after the body, letting the server stream without buffering to precompute a length.
Three pieces interlock: transfer must be Transfer-Encoding: chunked, the server pre-announces which trailers are coming via the Trailer header, and the client must indicate `TE: trailers` to accept them. Headers involved in framing or routing — Content-Length, Transfer-Encoding, Content-Encoding, Host — cannot be sent as trailers, because they're needed before the stream is interpreted.
Many HTTP/1.1 clients and proxies ignore or strip trailers, so it's safest to put only 'nice to have' extra information in a trailer, not required essentials. In HTTP/2 and HTTP/3, trailers are carried by frames (a trailing HEADERS frame) instead of chunked coding, but the concept is the same. gRPC's carrying of status codes in trailers is the canonical example.
Trailer: <header-name>[, <header-name>]*e.g. Trailer: Expires, Content-Digest