An HTTP server can send a 103 Early Hints response before the final response. The interim response may contain Link headers that help a browser preload resources or preconnect to another origin. The mechanism can improve perceived performance, and it can also expose routing, origin, and privacy assumptions that teams have not reviewed.
RFC 8297 defines the informational response. It is generated by an origin or an intermediary and can carry hints that a client may act on before the final status and body arrive. The client is not required to follow every hint. That flexibility is useful, but it means test results and browser behavior may differ across versions and network paths.
The hint is not the final response
An Early Hints response can include a preconnect to an origin that later redirects, fails, or serves a different resource. It can also advertise a resource that the final response does not use. If the hint is generated from a shared template, a cache, or an edge rule that is not aligned with the application's authorization, one user may receive a hint for another tenant's endpoint.
The safe baseline is to generate hints from the same request context and policy as the final page. Do not use a generic origin-wide list when the page has tenant-specific, feature-specific, or regional dependencies. Review the values that are allowed to appear in a Link header and reject user-controlled input before header construction.
Keep the origin inventory short
Preconnect hints can cause DNS resolution and connection establishment to an advertised origin before the user requests a resource. Treat the decision as a privacy and attack-surface control. Build a small allowlist of origins that can appear in hints. For each origin, record:
the service owner;
the certificate and hostname;
the expected resource types;
whether third-party cookies or credentials can be sent;
the purpose of the connection;
the removal date if the dependency is temporary.
Review the allowlist when a CDN, analytics vendor, or regional endpoint changes. A hint to an old vendor can continue sending metadata to a domain that is no longer part of the application.
Cache behavior needs explicit tests
Early Hints can be cached or forwarded by intermediaries even when the final response is not cacheable. Test the path from the origin through every proxy, CDN, and load balancer. Check whether the hint is generated on a cache hit, a miss, an error response, and an authenticated request.
Include a test for an unauthenticated request to a protected page and an authenticated request to the same URL. The interim response should not reveal tenant identifiers, private endpoints, or internal hostnames. If the hint contains links to a storage bucket, verify that the URL itself is not a private access token or a signed resource that expires independently of the page.
Observe client behavior without treating it as proof
Browser support for Early Hints varies. A browser may ignore a hint when it has a cached connection, when the connection is closed early, or when its preload policy declines the request. Measure the final resource timing, the connection destinations, and whether a 103 response appeared.
Server logs should distinguish the interim response from the final response. Keep the request ID, the hinted origins, and the final status together. If possible, record whether the connection was reused. These fields help explain why a user received a slow or unexpected load without requiring the team to inspect the full network trace.
Rollout and rollback
Start with one low-risk page and a small origin set. Compare the final response, connection destinations, certificate errors, and cache hit behavior with the page before the change. Add hints only after the origin inventory is reviewed.
Rollback should disable hint generation without changing the page's final response. Keep the configuration in a reviewed deployment file rather than in application code that is hard to change. If an intermediary generates the hints, make the rollback part of the intermediary's change process.
Early Hints can be a useful optimization. The useful security question is whether the server is revealing or prefetching something that the final response would never have allowed.