What is an HTTP 1xx interim response, and how does an exchange that includes 100 Continue or 103 Early Hints differ from an ordinary request/response pair?

## Interim vs final HTTP's basic shape is one request, one response. The 1xx class is the exception: an interim response consists of the status line and an optional set of header fields, is **always** terminated by the end of the header section, and **never** carries content. It does not complete the exchange — the server will still send a final response with a 2xx–5xx code. A client that stops reading after a 1xx has mis-parsed the exchange. Because any server may send an interim at any time, RFC 9110 requires clients to be able to parse and simply ignore 1xx codes they do not recognize. That is what makes the class extensible. ## 100 Continue The expectation mechanism exists so a client does not waste bandwidth uploading a body the server will refuse. The client sends the request head with `Expect: 100-continue` and pauses instead of streaming the body. The server, which now knows the method, target, credentials and declared `Content-Length`, either replies `100 Continue` — meaning "headers accepted, send the body" — or short-circuits with a final response such as 401 Unauthorized, 403, 413 Content Too Large or 417 Expectation Failed. The practical hazard is waiting forever. Some servers and proxies never emit the interim, so clients arm a short timer (curl uses one second) and send the body anyway when it expires. That is why an upload through a badly behaved proxy shows a fixed one-second stall per request — a classic latency mystery. Servers, symmetrically, must not require the expectation from clients that did not offer it. ## 101, 102, 103 - **101 Switching Protocols** answers an `Upgrade` request and marks the point where the connection stops speaking HTTP/1.1 and starts speaking something else, typically WebSocket. It is formally 1xx but ends HTTP semantics on that connection. HTTP/2 has no 101 at all; protocol switching there uses extended CONNECT. - **102 Processing** was a WebDAV keep-alive hint for long operations and is now deprecated — it never solved the timeout problem it was invented for. - **103 Early Hints** is the modern reason the class matters. The origin, before it knows the final status, sends `103` with `Link: </app.css>; rel=preload; as=style` headers. The browser begins fetching those assets while the server is still querying databases, recovering hundreds of milliseconds of critical-path time. Multiple 103s may be sent, and the hints are advisory: the final response still governs. Because some old intermediaries mishandled unexpected interims, deployments usually gate 103 on HTTPS/h2 connections. ## Versions In HTTP/1.1 an interim is literally an extra status line and header block on the wire before the real one, which is why buggy parsers concatenate them. In HTTP/2 and HTTP/3 interims are ordinary HEADERS frames whose `:status` is 1xx and which do not set END_STREAM, so the multiplexed framing layer handles them cleanly and there is no ambiguity about where the final response begins. ## When it shows up in practice Large uploads and API gateways (100), WebSocket handshakes (101), and page-load performance work at the CDN edge (103). Debugging tools hide interims by default — `curl -v` shows the `< HTTP/1.1 100 Continue` line, browser devtools generally do not — so engineers often meet 1xx first as a stall or an unexplained duplicate header block in a proxy log.