100 Continue

Informational - Continue with the request

HTTP 100 Continue

What It Means

The HTTP 100 Continue status code is an informational response indicating that the initial part of a request has been received and has not been rejected by the server. The client should continue sending the request body.

How It Works

The 100 Continue mechanism optimizes large POST/PUT requests:

  1. Client sends headers with Expect: 100-continue
  2. Server validates headers (authentication, content-length limits, etc.)
  3. If valid, server responds with 100 Continue
  4. Client sends the request body
  5. Server processes and sends final response (200, 201, etc.)

When It's Used

  • Large file uploads: Check if server will accept before sending megabytes
  • Authentication: Verify credentials before sending body
  • Content validation: Check Content-Type is acceptable

Example Request/Response

# Client request
POST /upload HTTP/1.1
Host: api.example.com
Content-Type: application/octet-stream
Content-Length: 104857600
Expect: 100-continue

# Server response (if OK to proceed)
HTTP/1.1 100 Continue

# Client then sends body...
[104857600 bytes of data]

# Server final response
HTTP/1.1 201 Created

Server Alternatives

Instead of 100 Continue, the server might respond with:

  • 417 Expectation Failed: The Expect header cannot be met
  • 401 Unauthorized: Authentication required before proceeding
  • 413 Payload Too Large: Content-Length exceeds server limits

Frequently Asked Questions

What is the HTTP 100 Continue status code used for?
HTTP 100 Continue is an informational response that tells the client its request headers have been received and the server has not rejected the request. The client should proceed to send the request body. This is used to optimize large uploads by checking authorization and validity before transmitting the full payload.
How does the Expect: 100-continue header work?
When a client includes the 'Expect: 100-continue' header, it pauses after sending headers and waits for the server to respond. If the server sends 100 Continue, the client sends the body. If the server sends an error (like 401 or 413), the client avoids sending the large body unnecessarily, saving bandwidth and time.
What happens if the server does not support 100 Continue?
If the server does not understand the Expect header, it should respond with 417 Expectation Failed. However, most modern servers support 100 Continue. If no response comes within a reasonable timeout, the client should send the body anyway to maintain compatibility with older servers.
Is the 100 Continue response visible to developers?
Usually not. Most HTTP client libraries (like curl, axios, or fetch) handle the 100 Continue exchange automatically and transparently. The developer typically only sees the final response (200, 201, etc.). However, you can see it with verbose logging or packet capture tools like Wireshark.
When should I use Expect: 100-continue in my API?
Use it when sending large request bodies (file uploads, large JSON payloads) to endpoints that may reject the request based on headers alone (authentication, content-type validation, size limits). This prevents wasting bandwidth by sending megabytes of data only to receive an authorization error.

Monitor your API responses

UptimeSignal verifies your endpoints respond correctly.

Start monitoring free →

Related Status Codes

More Resources