Does 103 Early Hints replace HTTP/2 server push?

It covers much of the same need. Instead of the server pushing files, it tells the browser which files to fetch, so the browser can use its cache and skip anything it already has.

Do I need to change my application to use 103?

Not always. Some CDNs and proxies can generate Early Hints from the Link headers your origin sent on earlier responses. Others need the application or web server to emit the 103 itself.

Can a 103 response include cookies or a body?

It cannot have a body, as no 1xx response can. Browsers generally only act on preload and preconnect Link headers in a 103 and ignore other headers there, so set cookies on the final response.

103 Early Hints — HTTP Status Code

103 Early Hints is a head start. Before a server has finished building a response, it sends a short interim message listing resources the page will need, such as a stylesheet, a web font or a script. The browser can begin fetching them in parallel, and the real response, typically a 200 OK, arrives afterwards.

What 103 means

103 is not in RFC 9110. It is defined in RFC 8297, published in 2017 as an Experimental RFC. The code indicates that the server is likely to send a final response containing the header fields included in the 103.

Key rules from the RFC:

The headers in a 103 are hints only. They do not replace the headers on the final response, and a client must not treat them as metadata about the 103 itself.
Apart from performance work such as preloading, acting on the hints must not change how the final response is processed.
A server can send more than one 103 before the final response, and it may later decide not to repeat a hint in the final headers if it turns out to be wrong.
Missing headers in a 103 mean nothing. A client should not assume a header is absent from the final response just because the hint left it out.

Like every 1xx response, 103 ends with its headers and carries no content.

When you see it

The classic case is a page whose HTML takes time to generate: a database query, a call to an upstream service, server-side rendering. The server already knows the page will need /app.css and a font file, so it sends:

HTTP/2 103
link: </app.css>; rel=preload; as=style
link: <https://fonts.example.net>; rel=preconnect

HTTP/2 200
content-type: text/html; charset=utf-8
link: </app.css>; rel=preload; as=style
...

Who sends it:

CDNs and edge proxies. Several CDNs can emit Early Hints on your behalf, typically by remembering the Link headers from earlier responses for the same URL.
Application servers and frameworks. Some web servers and frameworks have an API to flush a 103 before the final response is ready.
Not your browser. 103 only flows from server to client.

Browser support varies, and the browsers that do act on 103 generally do so only over HTTP/2 or HTTP/3 and only for preload and preconnect hints. A client that does not understand the hints simply ignores them, which RFC 9110 allows for unexpected 1xx responses, so sending 103 is low risk.

Common pitfalls

Old HTTP/1.1 clients. Some clients mishandle an informational response they did not ask for. RFC 8297 warns that an HTTP/1.1 client treating a 103 as final can mix up the responses that follow on the same connection, and suggests servers avoid sending 103 over HTTP/1.1 unless the client is known to cope.
Hinting the wrong files. Preloading resources the page does not use wastes bandwidth. Keep the list short and accurate.
Hints sent before the outcome is known. If the final response turns out to be a redirect or an error, the preloaded resources may be wasted. A CDN that replays hints learned from earlier responses can be especially prone to this after a deploy changes asset names.

How to check it

curl prints interim responses in verbose mode:

curl -sv -o /dev/null https://www.example.com/

Look for two response lines in order:

< HTTP/2 103
< link: </app.css>; rel=preload; as=style
< HTTP/2 200

If you only see the 200, the server or CDN is not sending Early Hints for that URL, or only sends them on a later visit once it has learned the Link headers.

What it means for uptime monitoring

A 103 is never the result a monitor judges. PingRobot's checker sends a GET and evaluates only the final response after any redirects: 200 to 399 is up, everything else is down. Interim responses, including 103, are consumed by the HTTP client before that point. A keyword monitor then searches the first 512 KB of the final body, not anything in the hints.

That means Early Hints can never make a broken page look healthy. If the server sends a 103 and then fails with a 500, the check records a 500. Monitor the page itself, ideally with a keyword that only appears when it rendered fully.

100 Continue — interim go-ahead for request bodies
101 Switching Protocols — interim response that hands the connection to another protocol
200 OK — the usual final response after Early Hints
304 Not Modified — another way to save the browser work, using its cache

Start monitoring free — 10 monitors, no credit card.