# HTTP 100 Continue

**Code:** `100` · **Category:** HTTP · **Seen on:** REST API

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

## 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?

---
Source: [WhatIsMyError](https://whatismyerror.com/errors/http/100-continue)