HTTP 100 Continue — What It Means & How to Use

HTTP 100 Continue is an informational response telling the client to proceed with sending the request body — used to avoid sending large payloads that would be rejected.

What It Means

The HTTP 100 Continue status code is part of the Expect: 100-continue handshake mechanism defined in RFC 7231. It belongs to the 1xx informational class, meaning the server has received the request headers and the client may continue with sending the body. This is a preliminary response — the final status code arrives after the full request is processed.

When a client sends a request with the Expect: 100-continue header, it is asking the server: “Before I upload a potentially large payload, will you accept it?” The server can respond with:

• 100 Continue — proceed with the request body
• 417 Expectation Failed — the server cannot handle the request (e.g., Content-Type not supported, payload too large without a proper error)
• 4xx or 5xx directly — some servers skip the 100 and respond with the final error immediately

The key benefit is bandwidth preservation. Without this mechanism, a client might upload megabytes of data only to receive 413 Payload Too Large or 415 Unsupported Media Type. The 100 Continue handshake lets the client check before committing to the upload.

When It’s Sent

• Large file uploads — the client sends Expect: 100-continue, waits for the go-ahead, then streams the file
• API requests with large JSON/XML bodies — POST or PUT requests with payloads exceeding several KB
• Conditional uploads — when the client is unsure whether the server will accept the media type or size
• Proxy forwarding — proxies may use 100 Continue to confirm the upstream server is ready before forwarding the body
• Resumable uploads — combined with Range headers for chunked upload scenarios

Real Example

curl -v -X PUT \
  -H "Expect: 100-continue" \
  -H "Content-Type: application/json" \
  -d '{"data": "large payload here"}' \
  https://api.example.com/upload

Expected response:

> PUT /upload HTTP/1.1
> Host: api.example.com
> Expect: 100-continue
> Content-Type: application/json
> Content-Length: 1024000
>
< HTTP/1.1 100 Continue
<
* We are completely uploaded and fine
< HTTP/1.1 201 Created
< Content-Type: application/json
< Content-Length: 45
<
{"status":"uploaded","id":"abc123"}

The client sees two response lines: 100 Continue (interim) followed by the final 201 Created. The actual body is only sent after the 100 response is received.

How to Debug

Client-Side

1. Verify the Expect header — check that your HTTP client is sending Expect: 100-continue. Many libraries (curl, requests) do this automatically for large payloads.
2. Check for timeout — if the server never responds with 100, the client waits and eventually sends the body anyway (most clients have a 1-second timeout).
3. Inspect with tcpdump or Wireshark — look for the two-round-trip pattern: headers sent, 100 received, body sent, final response received.

Server-Side

1. Check server logs — look for 100 Continue entries or 417 Expectation Failed responses
2. Review web server config — Nginx and Apache have directives controlling Expect header handling
3. Test without the Expect header — if the issue disappears, the handshake logic is the culprit

curl

curl -v --expect100-timeout 2 https://api.example.com/upload

The --expect100-timeout flag controls how long curl waits for the 100 Continue before sending the body.

Common Causes

FAQ

Related Codes

• HTTP 200 OK — the final success response after the body is accepted
• HTTP 413 Payload Too Large — what happens when the body exceeds server limits
• HTTP 417 Expectation Failed — the server refuses the Expect header value
• HTTP 415 Unsupported Media Type — the server rejects the Content-Type after the handshake