100 Continue

HTTP 100 Continue is an interim response defined for the Expect: 100-continue negotiation. A client that plans to send a large or conditional request body first transmits only the request line and headers, including the Expect header, then pauses. The server inspects the headers alone, method, authentication, content length, path, and decides whether the request is likely to succeed before the body arrives. If it is, the server replies 100 Continue and the client proceeds to stream the body; if the server can already tell the request will fail, it returns the final status directly and the client can skip the upload.

This handshake exists to avoid wasting bandwidth and time on uploads that are doomed to be rejected, most commonly large file uploads, PUT requests with sizable payloads, or POST bodies gated by authentication. Command line tools like curl add the Expect header automatically once a body crosses roughly one kilobyte, and many HTTP client libraries do the same. Because the 100 response carries no body and is not the final answer, clients must keep reading until a genuine final status line arrives; well behaved HTTP/1.1 stacks handle this transparently, but naive raw socket implementations sometimes stall waiting for a response that never comes.

Servers that do not understand or support the mechanism are expected to ignore an unrecognized Expect header and respond as normal, though HTTP/1.1 technically permits returning 417 Expectation Failed instead. Reverse proxies and load balancers occasionally interfere by buffering the whole request before forwarding it, which defeats the purpose but rarely breaks correctness. In HTTP/2 and HTTP/3 the same interim exchange is carried as a separate informational HEADERS frame rather than a distinct message, so the semantics survive even though the wire format changes. Clients should always cap how long they wait for the interim reply.