1xx informational status codes

What an interim response is

Every other status family ends the exchange. A 200, a 404 or a 502 is the server's final word on that request. A 1xx is different: the server sends the status line and any headers, then keeps the connection open and sends a second response later. RFC 9110 requires clients to be able to read one or more 1xx responses before the final one, and it allows any client that does not understand a particular 1xx code to ignore it.

The interim response is discarded once the final one arrives, so most tooling never shows it. Your browser's network panel, your web server's access log and a monitoring check all report the final status. The interim response did its job at the transport level and disappeared.

The 1xx codes you may run into

• 100 Continue. The client sent request headers with Expect: 100-continue and paused before sending a large body. A 100 means "headers look fine, send the body". If the server would reject the request anyway, it can answer with a final error instead and the client never wastes bandwidth uploading the payload. This is the one 1xx code that does useful work on ordinary sites, usually behind large file uploads and API clients such as curl.
• 101 Switching Protocols. The client asked to change protocol with an Upgrade header and the server agreed. This is the normal, successful outcome of a WebSocket handshake, so a 101 in a log is generally a good sign, not an incident.
• 102 Processing. Defined by the WebDAV specification for long-running requests, so the client knows the server has not stalled. It is rarely implemented outside WebDAV and you are unlikely to meet it on a normal website.
• 103 Early Hints. The server sends Link headers early, before it has finished generating the page, so the browser can start preloading stylesheets, fonts or scripts while the HTML is still being produced. It is a performance feature, not an error signal, and you normally turn it on deliberately at the CDN or the origin.

Why a 1xx is not something to fix

A 1xx on its own carries no fault. There is no such thing as a page that "returns 100" or "returns 101" in the way a page can return 404. If you have a problem and a 1xx is somewhere in the exchange, the interesting information is always the final status code that followed it, or the fact that no final response arrived at all.

The real failure modes near 1xx show up as a hang or a final error rather than as the 1xx itself:

• An old proxy or load balancer that does not forward interim responses, so a client waiting for 100 Continue stalls until its own timeout fires.
• A WebSocket upgrade that never reaches a 101 because a proxy in front of the application strips the Upgrade and Connection headers. The connection then falls back or fails outright.
• Early hints emitted with links to resources that no longer exist, which wastes requests without breaking the page.

How to see a 1xx response yourself

1. Use a verbose client. Ordinary curl -I shows only the final response headers, so ask for the full exchange instead:

   curl -v -H "Expect: 100-continue" --data-binary @big.bin https://example.com/upload

   A cooperating server answers HTTP/1.1 100 Continue before the body goes out, and then the final 2xx or 4xx.
2. For a WebSocket path, check that the handshake reaches HTTP/1.1 101 Switching Protocols. If it does not, look at the proxy layer first: upgrade headers are hop-by-hop, and several common reverse-proxy configurations drop them by default.
3. For early hints, request the page and look for a 103 block ahead of the final response. Not every intermediary passes it through, so an absent 103 does not always mean the origin is not sending one.
4. If a large upload hangs with no response at all, retry without the Expect header. If the retry succeeds, something between you and the origin is swallowing interim responses.

Monitoring an exchange you cannot see

Because 1xx codes never reach a log or a dashboard, what you monitor is the final answer and how long it took to arrive. An upload path stalled on an interim response looks from the outside exactly like a slow or timing-out endpoint, and an external check sees that at once. HostTracker runs checks from 300+ checkpoints in 158 cities, so a request that hangs behind one particular network path is distinguishable from a genuine outage. Run a URL through the HTTP check tool to see the final status and response time. The 2xx success codes and 3xx redirection codes guides cover the responses that do end an exchange.