100 - Continue

Start Here

Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.

This page is part of the Error Reference library. Learn more about the project or report a correction.

What Does Continue Mean?

HTTP 100 acts as a "checkpoint." When a client sends a large payload (e.g., >1MB), it first sends the headers with "Expect: 100-continue". The server validates authentication and file limits before the client spends bandwidth on the body. If the server rejects the headers (e.g., 401 Unauthorized), it saves the client from a useless, expensive upload. A failed 100-handshake usually manifests as a mysterious delay or a client-side hang.

Common Causes

• -Proxy Interception: Reverse proxies (like Nginx) stripping the "Expect" header, causing the backend to never see the switch request.
• -Load Balancer Timeout: AWS ALB or other edge devices terminating the 100-handshake prematurely, leading to 502 Bad Gateway errors.
• -Wait-and-Send Race: The client (like curl) waits only 1 second for a 100 response before sending the body anyway, causing confusion in high-latency links.
• -Legacy Server Rejection: Older API servers returning 417 Expectation Failed because they do not recognize the Expect mechanism.

How to Fix Continue

1. 1Configure Nginx Passthrough: Add proxy_set_header Expect $http_expect; to ensure the header reaches your upstream application.
2. 2Client-Side Fallback: If the server returns 417, configure your HTTP client to send the body immediately without waiting for confirmation.
3. 3Explicit Server Listeners: Ensure your backend (Node.js/Go/Python) is explicitly listening for the "checkContinue" event if it isn't handled automatically.
4. 4Adjust Timeout: Increase the client's "expect-timeout" if your server performs complex header validations (e.g., heavy database-backed auth).

Step-by-Step Diagnosis for Continue

1. 1Run curl -v -H "Expect: 100-continue" -d "test-body" [URL] and check for the interim "HTTP/1.1 100 Continue" line.
2. 2Audit proxy logs for a 1-second gap between the header-send and body-send; this confirms a "Missing 100" hang.
3. 3Verify the 417 Expectation Failed status in response headers, which points directly to an unsupported expectation.
4. 4Test the application server directly without the proxy layer to isolate where the Expect header is being dropped.

curl -v -H "Expect: 100-continue" \
     -X POST --data-binary @largefile.zip \
     https://api.errorreference.com/v1/uploads
# Look for interim status line:
# > Expect: 100-continue
# < HTTP/1.1 100 Continue

location /uploads/ {
    proxy_pass http://backend_app;
    proxy_http_version 1.1;
    proxy_set_header Expect $http_expect; # Crucial fix
}

Seen in Production

Debugging Tools

• -curl -v: The standard for seeing the informational 100 line.
• -Wireshark: To verify no body bytes are on the wire before the 100 status.
• -Nginx Access Logs: Check $upstream_status for interim responses.

How to Verify the Fix

• -Confirm the initial request returns 100 Continue before any body bytes are transmitted.
• -Verify that unauthorized requests are rejected immediately at the header stage.
• -Ensure large file uploads no longer experience a fixed 1-second delay at the start.

How to Prevent Recurrence

• -IaC Templates: Include Expect header passthrough in all standard Nginx and Load Balancer Terraform/Ansible scripts.
• -API Smoke Tests: Include a test case with a large body and Expect: 100-continue to catch proxy stripping during CI/CD.
• -Monitoring: Alert on 417 Expectation Failed spikes, which indicate client-server protocol incompatibility.
• -Pro-tip: For internal services on high-speed networks, disabling Expect: 100-continue on the client can save 1 round-trip of latency without risk.

Related Errors

Official References

• -MDN Web Docs: 100 Continue
• -Everything curl: Expect 100-continue
• -RFC 9110 Section 15.2.1 — 100 Continue
• -HTTP Official Documentation