100 🌐 HTTP

HTTP 100 Continue

An interim response telling the client to go ahead and send the request body — normal when the client sent Expect: 100-continue.

Seen on: REST API

Meaning

Clients uploading large bodies can first send only the headers with Expect: 100-continue. The server answers 100 Continue if it will accept the body, or a final error (401, 413, 417) if it won’t, saving a wasted upload.

You mostly see it in curl -v output or logs. Problems come from servers/proxies that don’t support the handshake: the client waits about a second for a 100 that never comes, or the proxy answers 417.

Common causes

  • Client (curl, .NET HttpClient, PHP cURL) automatically sends Expect: 100-continue for large POST bodies
  • Old proxy or server that doesn’t implement the handshake, causing a delay
  • Logs/monitoring treating 100 as a final status

⚡ Quick fix

  1. Treat 100 as interim — the final status follows
  2. Remove the Expect header if a proxy mishandles it
  3. Look past the 100 to the real final response

Detailed fix by platform

curl

  1. curl -H 'Expect:' -T big.zip https://example.com/upload # empty value disables Expect: 100-continue

PHP

  1. curl_setopt($ch, CURLOPT_HTTPHEADER, ['Expect:']); // stop libcurl adding Expect: 100-continue

.NET

  1. client.DefaultRequestHeaders.ExpectContinue = false;

How to diagnose

  1. Request headers — Is Expect: 100-continue being sent?
  2. Final status — What comes after the 100?
  3. Delay — Does the upload stall ~1s before sending?

🔧 Still not fixed?

Many errors look alike. If the steps above didn’t solve it, one of these is probably what you’re facing:

🧠 Still stuck? Analyze your error

Paste the full message, response headers or stack trace — we'll detect the platform and point to the most likely cause.