Read the hint fields without applying them to 103
02A 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.
A hypothetical text/html hint does not attach an HTML representation to 103. Wait for the distinct final message and its actual fields/body.
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.
Interpret hints as preparation, not as authoritative final metadata.
- A client MUST NOT interpret 103 header fields as if they applied to the informational response itself, such as metadata about that 103.
- Aside from performance optimizations, evaluating the hint fields MUST NOT affect how the final response is processed.
- Like other informational responses, a 103 has no content or trailers (current HTTP semantics, RFC 9110 §15.2). The HTTP/1.1 blank line ends its header section; a later final response is a distinct message.
These are three separate field-reading examples. Link: </style.css>; rel=preload; as=style suggests a style fetch. A hypothetical Cache-Control hint is not permission to cache the 103 itself or override final no-store. A Content-Type hint does not give the 103 an HTML body. Layout is schematic; this guide does not implement a browser preload policy.
Read the RFC section ↗