Visual RFC.
ALL RFCs / RFC 8297
Read the RFC ↗
RFC 8297 / HINTS AND METADATA

Keep the final response authoritative

03

The 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.

DIAGRAMRead RFC section 2 ↗
RFC 8297 · § 2EXAMPLE
3 / 3
Keep the final response authoritativeThree independent fictional comparisons do not represent multiple final responses to one request. First103 predicts style css but final200 has newstyle css, so no union with the stale field is created. Second the actual final status is403 with no Link; an early hint cannot grant access or turn it into200. Third a103 containing only Link is followed by final Content-Type text html; absence from an incomplete hint SHOULD NOT be interpreted as a prediction of absence from the final response.Three independent final-response examplesEarlier 103Final 200Only Link givenContent-Type:text/htmlincomplete predictionMissing from hint ≠ missing from finalSHOULD NOT infer absence
03
Do not predict absence from an incomplete hint.

Another example’s 103 has only Link, while its final response includes Content-Type: text/html. Missing in the hint is not a prediction of missing in the final response.

Source for this drawing: RFC 8297 · Read RFC section 2 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
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

RFC 9110 HTTP RFC 8288 Web Linking

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Do not merge speculative fields into the final answer.

  • Header fields in a 103 provide hints only; they do not replace the fields on the final response. Typically fields repeat, but they need not.
  • A server MAY hint only some expected final fields. A client SHOULD NOT interpret a field’s absence from the hint as speculation that it is unlikely to appear in the final response.
  • Aside from performance optimization, evaluation of the 103 MUST NOT affect final-response processing. It cannot turn a later error into success or supply a final field that was omitted.
DETAILS

The replacement style link, 403 and absent-then-present Content-Type are independent fictional outcomes, not three final responses to one request. Preparatory work may be unnecessary or unused. These examples do not say clients must preload everything or apply hinted cache/security policy before knowing the final response. Target labels abbreviate the URI; complete Link syntax appears in the field and multiple-hint chapters.

Read the RFC section ↗

All chapters in RFC 8297

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗