Add a late trailer
04A trailer is a field sent after message content. A streaming proxy may learn about a failure only after its response headers have gone out.
Separate receiver example: a trailer names Other, which is absent from the header. Promotion skips it; it does not invent an additional hop. A sender without its own earlier member must not emit such a trailer.
Source for this drawing: RFC 9209 · Read RFC section 2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Proxy-Status MAY be sent as a trailer, but SHOULD NOT be unless it cannot be sent in the header section; trailers can be silently discarded along the path.
- Proxy-Status MAY be sent as a trailer, but SHOULD NOT be unless it cannot be sent in the header section; trailers can be silently discarded along the path.
- An intermediary MUST NOT send a Proxy-Status trailer unless the same message’s header already contains its own member, though parameters can differ.
- A client MAY promote trailer members: replace the first matching header member entirely, matching identifier characters without parameters; skip unmatched trailer members. Do not append them as new hops.
Matching is character-by-character, including case. Token Edge and String "Edge" have the same identifier characters for matching. Duplicate names match the leftmost corresponding member. Promotion is optional, and receiving a trailer is not guaranteed. The example uses the registered connection_read_timeout name (§2.3.10).
Read the RFC section ↗