HTTP 100 Continue

Quick reference

What HTTP 100 means

RFC 9110 defines 100 Continue as an interim response used to inform the client that the initial part of the request has been received and the client should proceed with sending the remainder, or, if the request has already been completed, to ignore this response. It is a 1xx informational code — not a final response, but a signal from the server that the request processing can continue.

The typical flow: a client wants to upload a large file. Before sending all the data, it sends the request headers with an Expect: 100-continue header and waits. The server checks the headers — authentication, content type, authorization, size limits — and if everything is acceptable, responds with 100 Continue. The client then sends the body. If the server would reject the request for any reason, it sends the error response (401, 413, 403, etc.) and the client does not waste time sending a body that will be rejected.

100 saves bandwidth and time for large uploads to endpoints that might reject the request based on headers alone. A 50MB upload rejected after headers-only validation wastes nothing. Without 100-continue, it wastes 50MB of upload bandwidth before the rejection arrives.

The Expect: 100-continue mechanism

How it works step by step:

// Client sends headers only, waits
POST /upload HTTP/1.1
Host: api.example.com
Content-Type: application/octet-stream
Content-Length: 52428800
Authorization: Bearer <token>
Expect: 100-continue

// Server validates headers, responds
HTTP/1.1 100 Continue

// Client sends the body
[52MB file data]

// Server processes and responds
HTTP/1.1 201 Created

If the server would reject the request, it sends the rejection before the client sends the body:

// Server rejects before body is sent
HTTP/1.1 413 Content Too Large

Most HTTP/1.1 clients implement this automatically for requests with large bodies. The Expect header is sent when the body exceeds a configurable threshold (typically a few KB).

Server behavior

HTTP servers must handle Expect: 100-continue in one of three ways: send 100 Continue to proceed, send a final response code (any 4xx or 5xx) to reject, or ignore the Expect header and send neither — in which case the client should send the body after a timeout. Servers that do not support 100-continue at all may return 417 Expectation Failed.

A server that receives a request with Expect: 100-continue and wants to reject it should send the rejection response immediately rather than waiting for the body. This is the main benefit of the mechanism.

FAQ

What does HTTP 100 Continue mean?

HTTP 100 is an interim signal telling the client it can proceed with sending the request body. It is sent in response to a request with an Expect: 100-continue header.

Do I ever need to handle 100 Continue in my application code?

Usually not. HTTP client libraries handle 100 Continue automatically. If you are implementing a raw HTTP client or server, you need to implement the Expect/Continue handshake according to RFC 9110.

What happens if the server does not send 100?

The client waits for a configured timeout (typically a few seconds) and then sends the body anyway. RFC 9110 acknowledges that not all servers implement 100-continue, and clients must eventually proceed regardless.

When does 100 Continue benefit performance?

When the server would reject the request based on headers — wrong authentication, wrong content type, too large — and the body is large enough that not sending it saves meaningful time and bandwidth.

Related resources

On this site: HTTP 100 Continue — full guide · HTTP 417 Expectation Failed · HTTP 413 Content Too Large · HTTP 101 Switching Protocols

Standards: RFC 9110 §15.2.1 · IANA HTTP Status Code Registry · MDN Web Docs: 100