HTTP Trailer Fields
Trailer fields are headers sent after a chunked or streamed message body, letting a server report checksums or status that only become known once the body is fully produced.
Definition
A trailer is a set of header fields placed at the end of a message body, announced up front in a Trailer header, that carries metadata computed while the body is streamed.
Context and scope
They are used by gRPC and streaming responses to deliver a final status or integrity value after the payload without buffering the whole body first.
Common misconceptions
- trailers are available on every response regardless of framing
- trailers are just a slower way to send ordinary headers
Anti-patterns
- relying on trailers when the response uses a fixed Content-Length
- assuming client libraries surface trailer values automatically
Related concepts
Related examples
Authoritative source
Definition
A trailer is a set of header fields placed at the end of a message body, announced up front in a Trailer header, that carries metadata computed while the body is streamed.
They are used by gRPC and streaming responses to deliver a final status or integrity value after the payload without buffering the whole body first. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.
When to use it
A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.
How it works
Trailers require a self-delimiting body, typically chunked transfer coding, because a fixed-length body has no framing point at which to introduce the final fields.
Many clients and intermediaries drop trailers silently, so an implementation must not place essential control information only there unless it has verified the whole path supports them.
Trade-offs and alternatives
gRPC encodes status and error details in trailers, which is why proxies that do not propagate them can turn a streamed call into an opaque failure. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.
Common misconceptions
A persistent misconception is that trailers are available on every response regardless of framing. Another is that trailers are just a slower way to send ordinary headers. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.
Anti-patterns to avoid
Two recurring anti-patterns are to relying on trailers when the response uses a fixed Content-Length and to assuming client libraries surface trailer values automatically. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include CAA Records Constraining Certificates, Equal-Cost Multipath Routing, TCP Zero Window and Flow Control.