100 Continue
The server has read the request headers, found nothing wrong with them, and is ready for the client to send the request body.
Status
HTTP/1.1 100 Continue
Details
- Category: 1xx
- Status: Standard. Registered with IANA and defined by a current standards-track RFC.
- Specification: RFC 9110 §15.2.1
- Cacheable: Not cacheable
- Response body: Must not be sent
- Retry: Not applicable
100 Continue answers a request that carried an Expect: 100-continue header. The client sends its headers, pauses, and waits for permission before uploading a body that may be large. If the server would reject the request outright (wrong content type, missing auth, body too large), it answers with a 4xx instead and the client never wastes bandwidth on the upload.
The 100 is interim: it is followed by the real final status on the same connection once the body has been received and processed. A client that sends Expect: 100-continue must not wait forever. RFC 9110 tells it to send the body anyway after a short timeout, because some servers and intermediaries ignore the expectation entirely.
Headers
- Expect: Request header that triggers this response. The only defined value is 100-continue.
Common causes
- The client sent Expect: 100-continue before a request body, typically a large PUT or POST.
- curl adds Expect: 100-continue automatically for bodies over 1KB, so the exchange shows up in verbose output without anyone asking for it.
- An HTTP client library is streaming an upload and wants an early rejection signal before it spends bandwidth.
How to fix it
As the client
- Treat 100 as a go-ahead and start writing the body. Do not surface it to application code as a result.
- Cap the wait. If no interim response arrives within a second or two, send the body regardless.
- Send an empty Expect header, or disable the expectation in the client, if a middlebox is swallowing the interim response. In curl that is -H 'Expect:'.
As the server
- Validate cheap things first (auth, content type, declared length) so a rejection arrives before the body does.
- Answer the expectation. A server that neither sends 100 nor a final status leaves clients stalled until their timeout fires.
- Never send 100 to an HTTP/1.0 client, which has no concept of interim responses.
Examples
PUT /uploads/archive.tar HTTP/1.1 Host: api.example.com Content-Length: 84213760 Expect: 100-continue HTTP/1.1 100 Continue HTTP/1.1 201 Created Location: /uploads/archive.tar
Notes for proxy users
Forward proxies must pass interim responses through untouched. A proxy that buffers the whole response before forwarding will hide the 100 and stall clients that are waiting on it, which looks like an upload hang rather than a proxy bug.