Mark Nottingham edited this page Jan 20, 2015 · 1 revision

This page documents use cases for trailers -- not strictly a HTTP extension, since they're already defined, but poorly supported.

ETags for dynamic content

A server that generates dynamic content may not be able to assign ETags (and other caching metadata) until the response is complete. For example, an ESI implementation might want to send an ETag without buffering the response. If client caches were to respect ETags and other caching metadata sent in trailers, they would not need to buffer.

(this use case has been brought up by Varnish users)

Content Signatures

Again, putting a signature in the trailers allows servers to avoid buffering content.

See this:

and the trailers portion of the above spec (which needs a major update to use Trailers correctly) here:

Response Time

For performance analytics servers could add a trailer record to indicate the server execution/response time. This could be either the date/time when the response finished writing or the duration/time it took to write the response. This can be useful in scenarios where the application server sits behind a load balancer, reverse proxy or other intermediary system that might skew the result.

Security Correlation Tokens

An application may not be able to issue correlation token cookies (to avoid XSRF attacks) on pages with forms until the form's HTML has been rendered server side.


Ability to "update an HTTP status code" when an issue is discovered in flight.


Pagination mechanisms can add a link ?afterId=42; rel="next" in a trailer. Such a mechanism would not paginate with a SQL limit statement but with WHERE id>42 LIMIT 20


Server-Timing metrics, as proposed by @igrigorik, would be best placed in a trailer. As with most use cases mentioned, leveraging a trailer allows the server to avoid buffering the response.