HTTP 103 Early Hints – Free, Online, Private

What HTTP 103 means

103 carries headers the client can use while the server is still computing the final response. In practice those headers are Link rel=preload or rel=preconnect, so the browser can fetch CSS and fonts before the HTML exists. The final response follows, usually 200, and it should repeat any links the document still needs. 103 is defined in RFC 8297.

103 Early Hints belongs to the 1xx informational class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 103

When you see HTTP 103 Early Hints, stop on that exact status line. 103 Early Hints lets the server send Link headers before the final response is ready. The trace that usually produces it: A CDN sent preload links while the origin was still rendering. The 1xx informational class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

Send 103 when you know the subresources early and the final document is slow, for example while a backend renders HTML. Do not send 103 instead of the document. Do not put cookies or anything sensitive in it. Intermediaries are allowed to drop 103, so the final response must stand on its own.

How to fix HTTP 103

To fix HTTP 103, change the condition that made the server choose Early Hints. Ignore 103 if you do not implement it, and keep reading. Do not resolve the request to the user when you see 103. Apply the links only as hints. Do not retry because of 103. Retry only if the final status says the request failed, and only if the method is safe. If the log line is a different code, leave this page. The mix-up people make with 103 is this one: It is not 102, which carries no links, and it is not a redirect. Nothing about 103 changes the URL.

• A client that does not understand 103 waited correctly and used the final 200.
• A buggy client treated 103 as final and rendered an empty page.
• Early hints listed a URL that the final HTML did not use, wasting a fetch.

An access log that only stores 103 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

HTTP 103 Early HintsHTTP/1.1 103 Early Hints
Link: </app.css>; rel=preload; as=style

The Link header is the payload. There is no body. Browsers that implement early hints may start the preload immediately. The following 200 OK should include the HTML and can repeat the Link. If the 200 never comes, the preloads were wasted and the navigation failed.

What the client should do

Ignore 103 if you do not implement it, and keep reading. Do not resolve the request to the user when you see 103. Apply the links only as hints.

103 itself is not cached as the representation. The resources it names are cached under their own URLs and their own cache rules.

Do not retry because of 103. Retry only if the final status says the request failed, and only if the method is safe.

Codes people confuse with HTTP 103

It is not 102, which carries no links, and it is not a redirect. Nothing about 103 changes the URL.