100 Continue 1xx

What does 100 mean?

A 100 Continue response is part of HTTP's Expect: 100-continue mechanism — it's the server's way of telling a client "I've seen your request headers, I'm willing to accept the body, go ahead and send it." It's an interim response: the server will follow up with a "real" final status code (200, 201, 400, etc.) after receiving and processing the body.

100 is unusual among status codes in that it's explicitly not the final word on a request — it's a mid-conversation checkpoint, part of a back-and-forth that most developers never see directly because HTTP client libraries handle the entire exchange internally.

How a 100 behaves

• It's only sent in response to Expect: 100-continue — without this header in the request, 100 doesn't come into play
• It's an interim response — a final status code (reflecting the actual outcome of processing the full request) follows afterward
• It has no meaningful body — it's purely a "proceed" signal
• Most HTTP libraries handle this transparently — when a library sends Expect: 100-continue (often automatically for larger request bodies), it also handles waiting for and processing the 100 response before sending the body, all without exposing this intermediate step to application code

Common scenarios

If you're building/operating the server:

• Your server supports Expect: 100-continue and responds with 100 when it's willing to accept an incoming body — this lets clients avoid sending large payloads that would be rejected anyway based on headers alone (e.g., wrong content type, missing auth)

If you're calling an API:

• Your HTTP client library may use Expect: 100-continue automatically for certain requests (often based on body size), receiving and processing 100 responses internally — you'd typically never see this in your application code's logic, only perhaps in low-level network traces

If you're a website visitor:

• Entirely invisible — this is a connection-level detail handled by browsers

Real-world examples

HTTP client libraries that implement Expect: 100-continue for PUT/POST requests above a certain size threshold handle the full 100-Continue exchange internally — from an application developer's perspective using such a library, you simply make a request and get a final response; the 100 (if it occurred) was handled "underneath" by the library before your code ever sees a result. Network-level debugging tools (packet capture tools, verbose HTTP client logging) are about the only context where developers typically see a 100 Continue response directly, since it's filtered out of the "normal" response by most libraries.

SEO implications

None — 100 is an interim, connection-level response invisible to search engine crawlers and irrelevant to page content.

FAQ

Will I ever see a 100 Continue response in my application code?

Almost certainly not, if you're using a standard HTTP client library — these typically handle the entire Expect: 100-continue exchange (sending the expectation, receiving 100, then sending the body, then receiving the final response) internally, exposing only the final response to your code.

What happens if a server doesn't support Expect: 100-continue?

Depending on the server/proxy, this could result in the request simply being processed normally (ignoring the Expect header and the body being sent regardless), or in some cases, 417 (Expectation Failed) if the server explicitly doesn't support the mechanism at all.

Is 100 considered a "success" or "error" response?

Neither, really — it's an interim/informational response (the 1xx range is specifically for this). It doesn't represent the final outcome of the request at all; that comes in a subsequent response.

Why does Expect: 100-continue exist if it's mostly invisible?

It exists as a bandwidth-saving optimization for cases where a server might reject a request based on headers alone (auth failure, wrong content type, etc.) — by checking first via 100-continue, a client can avoid sending a potentially large body that would just be rejected anyway. Its "invisibility" is actually the point — it's meant to optimize behind the scenes without requiring application-level awareness.

Can multiple 1xx responses be sent before the final response?

Yes — the 1xx range is designed to allow multiple interim responses (100, and others like 103 Early Hints) before the final response, and HTTP client implementations are expected to handle receiving and processing multiple interim responses correctly.

Fun fact

100 is part of the 1xx "informational" range — a category of status codes so rarely encountered directly that many developers could work in web development for years without ever knowingly seeing one, despite 1xx responses happening "under the hood" in various HTTP exchanges far more often than their near-total invisibility in application-level code might suggest.