100 Continue: What It Means and How It Works
How the 100 Continue Handshake Works
When a client needs to send a large request body (e.g., a file upload), it first sends the request headers including Expect: 100-continue. The server, upon receiving these headers, can either:
- Respond with 100 Continue — signaling the client to proceed with the body.
- Respond with a final status like 417 Expectation Failed — rejecting the request outright without the client wasting bandwidth on the body.
Example Request/Response Flow
| Step | Direction | HTTP Message |
|---|---|---|
| 1 | Client → Server | POST /upload HTTP/1.1 |
| 2 | Server → Client | HTTP/1.1 100 Continue |
| 3 | Client → Server | [1 MB of binary data] |
| 4 | Server → Client | HTTP/1.1 200 OK |
Browser Compatibility
Most modern browsers handle 100 Continue automatically for form submissions. Developers rarely need to deal with it directly unless they are building custom HTTP clients or servers. It is primarily a server-side concern.
Frequently Asked Questions
Do I need to send the 100 Continue response manually?
If you are using a standard web server (Apache, Nginx, IIS), it handles 100 Continue automatically when it sees the Expect: 100-continue header. You only need to worry about it if you are writing a custom HTTP server.
What happens if the server doesn't support 100 Continue?
An older server that doesn't understand the Expect header may simply ignore it and wait for the request body. The client, after a timeout (usually a few seconds), should proceed to send the body anyway to avoid hanging.
Is 100 Continue the same as 102 Processing?
No. 100 Continue is about the handshake before the request body is sent. 102 Processing is sent during the processing of a long-running request to keep the connection alive.