Handle more than one Early Hints response
04A server MAY send multiple 103 responses as more information becomes available. Each adds possible preparation, while a single eventual final response remains authoritative.
The final response lists /main.css, /newstyle.css and /script.js. The earlier /style.css prediction does not silently become a fourth final Link field.
Source for this drawing: RFC 8297 · 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.
A set of predictions is still not the final field set.
- Multiple 103 responses before the final response are allowed. Earlier fields need not be repeated, and repeating them is not forbidden.
- The client can consider any combination of fields from the hints when anticipating the final fields; it does not have to treat the latest hint as a complete replacement prediction.
- An intermediary can generate a hint from stale cached fields, then forward an origin hint and final response during revalidation. That is a possible source of multiple hints, not a claim that stale fields become final metadata.
The three style/script targets follow RFC 8297 §2’s concrete multiple-hint example. First /main.css; then /style.css and /script.js; final /main.css, /newstyle.css and /script.js. The final replaces one predicted value. Fetch scheduling, cache reuse, cancellation and the actual preload algorithm are outside this RFC’s definition.
Read the RFC section ↗