100 Continue
The initial part of the request was received; the client should proceed with sending the body.
Meaning & Description
This mechanism is designed to prevent clients from sending a massive request body (like a large file upload) when the server might reject the request based on headers alone, such as for missing authentication or unsupported content types.
Common Causes
- The client included an `Expect: 100-continue` header in the initial request.
- The client library automatically negotiates large payloads using this header (common in cURL, libcurl, and .NET).
How to fix a 100 error
- Check if the client sent the `Expect: 100-continue` header.
- Verify the server is properly configured to parse headers, emit the 100 response, and wait for the body.
- If using a proxy or API gateway, ensure it properly proxies the 100 response back to the client.
- If the request hangs after receiving a 100, verify the client is actually sending the body.
Browser & SEO Behaviour
Browser Behavior
Browsers generally do not send the `Expect: 100-continue` header for standard form submissions or fetch API requests.
SEO Impact
No direct SEO impact. Search engine crawlers rarely issue requests large enough to trigger `Expect: 100-continue`.
CDN Behavior
Most CDNs will proxy the `Expect: 100-continue` header to the origin, wait for the 100 response, and stream it back to the client before proxying the body.
Code Examples
POST /upload HTTP/1.1
Host: example.com
Content-Length: 9999999
Expect: 100-continue
HTTP/1.1 100 Continue
[...client sends body here...]const http = require('http');
const server = http.createServer();
server.on('checkContinue', (req, res) => {
if (req.headers['authorization']) {
res.writeContinue();
req.pipe(processUpload());
} else {
res.statusCode = 401;
res.end('Unauthorized');
}
});import requests
# Python requests does not support Expect: 100-continue natively.
# You must use a session or a custom transport adapter,
# or rely on lower-level libraries like http.client for granular control.
import http.client
conn = http.client.HTTPSConnection("example.com")
conn.putrequest("POST", "/upload")
conn.putheader("Expect", "100-continue")
conn.endheaders()package main
import (
"net/http"
"strings"
)
func main() {
req, _ := http.NewRequest("POST", "http://example.com/upload", strings.NewReader("body data"))
// Go's net/http client automatically adds Expect: 100-continue
// for requests with bodies larger than a certain threshold.
req.Header.Set("Expect", "100-continue")
client := &http.Client{}
client.Do(req)
}# curl automatically sends Expect: 100-continue for payloads > 1024 bytes.
# To explicitly disable it:
curl -X POST -H "Expect:" -d @largefile.zip https://example.com/upload
# To explicitly force it (rarely needed):
curl -X POST -H "Expect: 100-continue" -d @file.txt https://example.com/uploadRaw HTTP Response Example
HTTP/1.1 100 Continue
HTTP/1.1 200 OK
Date: Mon, 23 May 2026 22:38:34 GMT
Content-Type: application/json
Content-Length: 26
{"status": "upload_complete"}Real-world Examples
Frequently Asked Questions
Do all HTTP clients support 100 Continue?
No. While curl and Go's net/http support it natively, many high-level libraries like Python's `requests` or JavaScript's `fetch` do not send `Expect: 100-continue` by default and require custom implementation.
What happens if a server does not support 100 Continue?
If a server doesn't understand the `Expect` header, it will typically just wait for the body. To prevent deadlocks, clients usually implement a timeout (e.g., 1-3 seconds) and will proceed to send the body if no 100 Continue response is received.
Can a server send a final status code instead of 100 Continue?
Yes. If the server evaluates the headers and determines the request should fail (e.g., a 401 Unauthorized or 413 Payload Too Large), it will immediately send that final status code and close the connection, skipping the 100 Continue entirely.
Is 100 Continue used in HTTP/2 and HTTP/3?
Yes, the semantic concept remains the same in HTTP/2 and HTTP/3, though it is implemented as a HEADERS frame containing the 100 status code before the client sends DATA frames.
Why does curl pause for a second during uploads?
This is often the 100 Continue timeout. If curl sends `Expect: 100-continue` and the server doesn't respond with a 100 status, curl waits for 1 second before giving up on the expectation and sending the body anyway.
Did You Know?
The 100 Continue mechanism was introduced in HTTP/1.1 specifically to save bandwidth during large PUT or POST operations.
A single HTTP request can technically receive multiple 1xx informational responses before receiving the final 2xx-5xx response.
If you see `HTTP/1.1 100 Continue` printed in your terminal during a curl request, it means curl sent the `Expect` header and the server explicitly acknowledged it.
Developer Tips
- If you are building an API gateway or reverse proxy, ensure it handles `Expect: 100-continue` correctly by forwarding the expectation to the upstream server.
- To suppress curl's automatic `Expect` header (which can cause 1-second delays with non-compliant servers), pass `-H "Expect:"` (an empty header value).
- When implementing a Node.js HTTP server, use the `checkContinue` event to handle these requests manually, otherwise Node defaults to sending the 100 response automatically.
- Always authenticate requests based on headers before sending a 100 Continue response to minimize wasted bandwidth.
Interview Questions
These are questions you might face in a backend or API design interview that touch on HTTP 100.
What is the purpose of the 100 Continue status code?
It is an optimization for large payloads. It allows a client to send request headers with `Expect: 100-continue` and wait for the server's approval before sending the heavy request body. If the server rejects the headers (e.g., 401 Unauthorized), bandwidth is saved.
How do you bypass a server that ignores the Expect header but doesn't send a 100 Continue?
Clients typically implement a timer. If the server does not respond with 100 Continue within a short period (often 1 second), the client will assume the server doesn't support the mechanism and will transmit the body anyway.
Can a server send a 4xx error instead of a 100 Continue?
Yes. The entire point of the mechanism is to allow the server to reject the request early. Sending a 401 Unauthorized or 413 Payload Too Large immediately is the correct behavior if the headers do not pass validation.
Common Interview Mistakes
- Assuming that the client must wait indefinitely for a 100 Continue before sending the body. Clients must implement a timeout.
- Confusing 100 Continue with a final successful response. It is strictly an interim informational message.
- Thinking that browsers use this for standard POST forms. It is primarily used by programmatic clients and CLI tools for large uploads.