Summary

  • HTTP 103 carries header fields that are likely, but not guaranteed, to appear in the final response. A client may use a preload hint to begin a resource fetch, yet the interim fields neither replace the final headers nor change how the final response is processed.
  • Authority remains divided: an origin or cache intermediary may emit the hint; the user agent admits or ignores speculative work; the final response determines the request result; and the hinted resource still faces ordinary connection, security, cache and reuse rules.

The application has received a navigation request. Its template is known, but a database query will decide whether the user sees a dashboard, a login redirect or an error. At the edge, yesterday's successful response says that shell.css was important. Waiting for the complete answer preserves certainty and loses a round trip. Sending the stylesheet as if the answer were already known spends bandwidth on a fact that may change.

RFC 8297 creates a deliberately weaker act. The server can send a 103 Early Hints response containing a Link field, then continue computing the final response. A browser that recognizes rel=preload can start fetching the target while the origin is still working.

The word hints carries the architecture. The server says that a field is likely to appear later. It does not say that the request succeeded, that the target will be used, or even that the final response will repeat the field. The client gets an opportunity to move before truth is complete, not a command to pretend that truth is complete.

One request, more than one response, one final result

RFC 9110 places 103 inside the informational 1xx class. A request may receive zero or more interim responses before one final response. An informational response ends at the header section; it has no content or trailers. A client must be able to parse interim responses, while a user agent may ignore an unexpected one.

Those rules prevent temporal advantage from corrupting message meaning. The early Link can be evaluated for a performance optimization, but RFC 8297 says that this evaluation must not otherwise affect processing of the final response. The final 200, 302, 404 or 500 remains the result of the original request.

Nor is omission meaningful. A 103 may contain only the fields known early. The absence of Content-Security-Policy, Link or any other field is not a prediction that the final response will omit it. Reading silence as a negative promise would turn an incomplete message into false authority.

The early and final sets may disagree. RFC 8297 illustrates multiple 103 responses followed by a final response that keeps some anticipated links and substitutes another. That is not protocol failure. It is the condition the status was designed to express: useful information existed before complete information.

Four owners on one short timeline

The origin owns its final response. It can choose to expose fields early, but it remains responsible for complete final headers and status. A caching intermediary can also become a hint source. RFC 8297 explicitly describes an intermediary emitting 103 from stale cached header fields while it revalidates, then forwarding the origin's own interim and final responses.

The user agent owns speculation. It can ignore 103, admit a preload, satisfy it from cache, schedule it behind other work, apply a byte budget or cancel usefulness after a redirect. A hint describes a candidate relationship; it does not reach inside the client's queue and allocate capacity.

The final response owns navigation meaning. A redirect can send the browser elsewhere. An error can end the anticipated document. A changed Link set can leave an early fetch unused. None of these outcomes needs permission from the hint.

The target resource owns a fourth result. DNS resolution, connection establishment, TLS authentication, request credentials, cache state, response status, content type and integrity checks still decide whether a usable object arrives. A preload of a URL is not proof of the bytes behind it.

RFC 8288 helps keep the grammar modest. A link has a context, relation type, target and optional target attributes. It states how resources are related. It does not authenticate the target, promise successful dereferencing or grant the linked object authority over its context.

The browser narrows the broad wire signal

The living HTML Standard makes browser behavior more concrete. Early hints are used during navigation so a user agent can speculatively load resources before the final document response. Current processing handles the first early-hint response for the navigation and discards it if a later redirect crosses origins.

Only a bounded set of preload attributes is available at this stage: as, crossorigin, integrity and type. Attributes that need a created document cannot all be acted upon early. Early Link processing comes before final-response Link fields and link elements in the document, but being first is not being final.

Policy can also arrive early. The HTML algorithm can create a policy container from an early Content Security Policy and use it for the speculative request. A stricter final policy may make an already fetched response unavailable to the document. The network expenditure happened; authority to use the result did not follow automatically.

The Fetch Standard retains the same boundary. A handled 103 enters an early-hints callback, then fetching continues because informational responses are eventually followed by the final response. The optimization lives inside the request lifecycle rather than replacing it.

Stale knowledge can be useful without becoming current truth

An intermediary's cached view creates the sharpest test. The cached page previously linked shell.css. That fact may be a good predictor while revalidation is pending. It may also be obsolete because the application now redirects, the asset name changed, or personalized state selects a different bundle.

Calling the cached header stale does not make it worthless. Calling it a hint makes its authority proportionate to its age. The edge can offer the prediction; the client decides the cost; the origin finishes the answer. A safe design does not allow the hint generator's speed to usurp the final-response owner's knowledge.

Provenance therefore belongs in observability. Operators should know whether a 103 came from the application, an edge rule or stale response metadata. They should capture the exact early header set and the final header set separately. If two layers can emit hints, their duplicate or contradictory candidates must remain visible rather than being flattened into a story that “the server sent a preload.”

Work can be irreversible even when meaning is provisional

A wrong early hint does not normally make the final page semantically wrong. It can still create real cost. A speculative request can reveal interest in a target, wake a third-party service, consume radio energy, occupy a connection, compete for congestion-window opportunity and add origin load. If the object is large or cross-origin, a few saved milliseconds for one path can become widespread waste.

The correct unit is not the number of 103 responses. It is useful early work. Measure whether the client received the hint, began the request earlier than it otherwise would have, obtained or reused the response, and allowed the final document to consume it. Pair the latency distribution with bytes, requests and connection slots spent on objects never used.

Compatibility also remains evidence, not assumption. RFC 8297 warns that an HTTP/1.1 client which mistakes an informational response for the final response can misframe later messages on a persistent connection and even create cross-origin disclosure risk. A server may therefore avoid 103 over HTTP/1.1 unless the client is known to handle it. HTTP/2 framing reduces that particular risk; it does not certify hint quality.

The IANA registry establishes that code 103 means Early Hints and points to RFC 8297. It prevents ambiguity in the shared code point. It cannot show whether an intermediary forwards it, a browser acts on it, an object is reused or a user benefits.

Heng Lu's principles of minimum shared specification and localized future decision fit the status unusually well. The shared layer says only what has to be interoperable: these fields are provisional and a final response is still coming. Adoption and resource allocation remain with implementations. Running-code primacy then supplies the test: capture what crossed the wire, what the client did and what the user received.

The result is a thin coordination mechanism with an honest failure mode. A client that ignores the hint should still receive a complete, correct final response. If disabling 103 breaks the page, the optimization has escaped its authority and become an undocumented dependency.