RFC 8297 / START HERE
103 Early Hints, before the details
HTTP means Hypertext Transfer Protocol. RFC 8297 defines 103 Early Hints, an informational response sent before a request’s final response.
A server can send likely response fields while it is still preparing the final answer. A client can use a preload Link hint to start fetching a potentially useful resource sooner.
The idea in one picture
Request a page
Prepare if useful
Read the final response
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
The final status and full fields can depend on slow upstream work. Early Hints separates optional preparation from final-response processing; it does not finish the request or guarantee that the predicted fields will remain correct. The original 2017 publication was Experimental; current RFC Editor metadata lists Proposed Standard.
A familiar example
A browser requests a page. An early Link suggests a style sheet; the browser may choose to fetch it while waiting. The final page can list a different style sheet or even return an error. Hints are not final metadata, access permission or a measured performance guarantee.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Prepare while the final response is pendingHTTP 103 Early Hints lets a server send likely response fields before it finishes preparing the final answer. A client can start useful work sooner.→
- Read the hint fields without applying them to 103A 103 carries header fields likely to appear on the final response. The fields do not describe a separate 103 representation and do not replace final response fields.→
- Keep the final response authoritativeThe server can learn new facts after sending a hint. An early field may change or disappear, and a field absent from the hint may still appear in the final response.→
- Handle more than one Early Hints responseA server MAY send multiple 103 responses as more information becomes available. Each adds possible preparation, while a single eventual final response remains authoritative.→
- Preserve response boundaries and choose compatible clientsMisreading an informational response as final can associate later bytes with the wrong request. Servers can choose not to send 103 to HTTP/1.1 clients whose handling is uncertain.→
This introduction explains RFC 8297 (2017). Read the original RFC ↗