Skip to content

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.

Note: Do not wait indefinitely for the interim response. RFC 9110 tells clients 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.

Usage notes

For clients

  • 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:'.

For servers

  • 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

Uploading a body behind Expect: 100-continue

HTTP request

PUT /uploads/archive.tar HTTP/1.1
Host: api.example.com
Content-Length: 84213760
Expect: 100-continue

HTTP response

HTTP/1.1 100 Continue

HTTP response

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.

Specifications

See also