Expect 100-Continue
The Expect 100-continue handshake lets a client ask the server whether a large request body is welcome before sending it, saving bandwidth on early rejections such as auth failures.
Definition
Expect: 100-continue is an opt-in request header that asks the server to return a 100 Continue interim response before the client transmits its body. The server can instead respond with an error like 401 or 413, letting the client skip sending a payload that would be discarded. Interim timeout handling is client-defined.
Context and scope
Used for large uploads to APIs where authentication, authorization, or size limits fail often, and on constrained networks where wasted upload bytes are expensive.
Common misconceptions
- The client must always wait for 100 — after a short timeout it should send the body anyway per the standard
- It applies to responses too — it is purely a request-body gate for the client to use
- Proxies pass it through transparently — some strip or mishandle Expect, so end-to-end behavior must be tested
Anti-patterns
- Sending Expect on every small request and adding a fixed extra round trip to all calls
- Never implementing the fallback timeout, so a server that ignores Expect stalls the upload forever
- Responding 100 Continue before validating auth or size, defeating the entire purpose of the handshake
Related concepts
Related examples
Authoritative source
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/100
What it is
Uploading a large body to a server that will reject it wastes the entire transfer. With Expect: 100-continue, the client sends headers only, waits briefly for permission, and sends the body only after 100 Continue. An early 4xx saves the payload transmission entirely.
How it works
The server inspects headers, then either writes 100 Continue and reads the body, or finalizes an error. A client whose interim wait times out must proceed to send the body anyway, because servers are permitted to ignore Expect. The mechanism is a courtesy protocol, not a guarantee.
When to use it
Large file upload APIs, authenticated ingestion endpoints, and metered or high-latency uplinks benefit most. Small requests should not use it: the added round trip costs more than rare rejections save.
Pitfalls
Intermediaries that answer 100 Continue without consulting the backend break the gate. Servers that never send 100 and never read the body trap clients lacking the timeout fallback. Load balancer buffering can also defeat streaming assumptions around the interim response.