HTTP trailer field (source code)

= HTTP trailer field
{c}

An <HTTP trailer field> is a message field carried in a trailer section after the content. It can provide metadata whose final value becomes available while the content is being generated or processed. Its placement lets a sender stream content before that metadata is complete.<HTTP Semantics>[§6.5, Trailer Fields, purposes and separation from header fields]{ref}

For a concrete <HTTP 1.1> example, define an illustrative extension field `Example-Count` to report the number of content octets and explicitly permit it in trailers. This is a definition for the example, not a standard field. A response can announce `Transfer-Encoding: chunked` and `Trailer: Example-Count` in its header section. Its following transfer-coded body, using visible escape notation, is `3\r\nabc\r\n0\r\nExample-Count: 3\r\n\r\n`.

Here `\r\n` denotes a carriage-return/line-feed pair in the actual stream. The three-octet chunk supplies `abc`. The zero-sized chunk ends the chunks, and `Example-Count: 3` then supplies the trailer metadata before the final empty line. The content is just `abc`; the trailer field is not appended to the representation data.<HTTP 1.1 (RFC 9112)>[§7.1, chunked grammar; §7.1.2, trailer section]{ref}

The initial `Trailer` field names metadata the sender anticipates sending. A recipient can use this announcement to prepare its processing, but it does not guarantee that every announced field will actually arrive. The field value itself remains in the later trailer section.<HTTP Semantics>[§6.6.2, Trailer field and announcement semantics]{ref}

Placement is constrained by semantics. A sender must know that a field's definition permits trailer use; fields needed earlier for <HTTP message framing>, routing or content interpretation generally cannot simply be moved to the end. A recipient must not merge trailer fields into the header section unless their definitions explicitly permit and define the merge.<HTTP Semantics>[§6.5.1, limitations and safe merging]{ref}

Trailers can also be discarded in transit, so an application cannot assume that arbitrary metadata placed there will reach or be acted upon by every recipient. Keeping <HTTP trailer fields> distinct from <HTTP header fields> preserves the distinction between information available before content processing and information learned afterwards.<HTTP Semantics>[§§6.5.1–6.5.2, intermediary handling and processing]{ref}