100 Continue — HTTP Status Code

100 Continue is the server saying "so far, so good, send the rest." It is an interim response: it arrives before the real answer, carries no body, and is always followed by a final status code once the server has received and processed the request.

What 100 means

RFC 9110 (Section 15.2.1) defines 100 Continue as a signal that the first part of a request has arrived and has not been rejected yet. The server still intends to send a final response after it has the full request and has acted on it.

The code exists to support a handshake set up by the Expect request header (RFC 9110, Section 10.1.1). A client that is about to upload a large body can send only the headers first, with Expect: 100-continue, and pause. The server then has two choices:

• Reply 100 Continue, and the client streams the body.
• Reply with a final error right away, such as 401 Unauthorized, 405 Method Not Allowed or 413 Content Too Large, and the client never wastes bandwidth sending gigabytes that would be thrown away.

If a client did not ask for it, a 100 response can simply be discarded. Like every 1xx code, it ends at the header section and cannot contain content.

When you see it

You will rarely meet 100 Continue in a browser. It shows up in tooling and server-to-server traffic:

• Command-line uploads. curl adds Expect: 100-continue to some larger POST and PUT uploads, so verbose output shows a 100 Continue line before the final status.
• API clients and SDKs. Object storage and backup tools often use the expectation for big file uploads so an authentication or size error is caught before the transfer starts.
• Proxies. A reverse proxy such as nginx can answer the expectation itself, or pass it on to the application. A proxy that added the Expect header on its own does not have to forward the resulting 100 to the original client.

RFC 9110 also says a server must not send any 1xx response to an HTTP/1.0 client, because HTTP/1.0 never defined the class.

Common problems around 100 Continue

The code itself is harmless, but the handshake can cause odd behavior:

1. Slow uploads. If a server or proxy ignores the expectation, the client waits for a timeout (curl waits about a second by default) before sending the body anyway. Many small uploads in a row make that delay noticeable.
2. Old intermediaries. A server that does not support expectations may answer 417 Expectation Failed. The client should then retry without the header.
3. Confusing logs. Some debugging tools print the 100 line first, which makes it look like the request ended with 100. It did not; read on to the final status.

To rule the handshake out when debugging, disable it on the client side:

curl -H "Expect:" -T backup.tar.gz https://upload.example.com/files/

How to check it

Send an upload with the expectation and watch the verbose output:

curl -sv -o /dev/null -H "Expect: 100-continue" \
  --data-binary @large-file.bin https://api.example.com/upload

A server that supports the handshake prints something like:

> Expect: 100-continue
< HTTP/1.1 100 Continue
< HTTP/1.1 201 Created

The < lines are responses. The first is interim, the second is the real result. If you see only one line, the server either skipped the 100 or answered with an error straight away. Note that curl -I sends a HEAD request with no body, so it will never trigger 100 Continue.

What it means for uptime monitoring

A 100 response is never the result a monitor judges. PingRobot's checker sends a plain GET with no request body and no Expect header, so servers have no reason to send 100 Continue to it at all. Even if an interim response did arrive, the HTTP client discards it and waits for the final status. The verdict is based only on that final response: a status from 200 to 399 counts as up, anything else as down, and keyword monitors then search the first 512 KB of the body for your text.

If an upload endpoint misbehaves around the Expect handshake, an uptime check will not reproduce it. Test that path with a scripted upload, or have the job that performs uploads report in through a heartbeat.

Related codes

• 101 Switching Protocols — the other interim code in RFC 9110
• 103 Early Hints — interim headers sent before the final response
• 413 Content Too Large — a typical refusal instead of 100
• 400 Bad Request — when the request itself is malformed
• 200 OK and 201 Created — common final answers after the body is sent

Start monitoring free — 10 monitors, no credit card.