417 Expectation Failed

The server cannot meet the requirements stated in the request's Expect header, most often Expect: 100-continue.

Defined in RFC 9110 §15.5.18

What 417 means

RFC 9110 defines the Expect request header as a way for a client to ask the server whether it will accept a request before the client commits to sending a potentially large body. The most common value is "100-continue": the client sends headers, waits for a 100 Continue response, and only then transmits the body. If a server or any intermediary cannot or will not meet that expectation, it responds with 417 instead.

In modern practice 417 is rare, because virtually every HTTP/1.1-compliant server and proxy understands 100-continue. It tends to surface with older or noncompliant intermediaries: a corporate proxy, an outdated load balancer, or a legacy version of IIS that rejects the Expect header outright rather than negotiating it, which breaks large PUT or POST uploads issued by clients (classically curl) that add Expect: 100-continue automatically.

Because the failure mode is almost always infrastructure rather than application logic, debugging 417 usually means checking every hop between client and origin for HTTP/1.1 compliance, not the application code that constructed the request.

Common causes

Client sends Expect: 100-continue and an intermediary proxy or older server does not support it.
A load balancer or WAF strips or mishandles the Expect header before it reaches the origin.
An HTTP client library (classically old curl or .NET's HttpWebRequest) automatically adds Expect: 100-continue for PUT/POST requests against a server with incomplete HTTP/1.1 support.
The server explicitly rejects any Expect value it does not recognize, per RFC 9110's guidance to fail fast rather than guess.

How to fix a 417

If you are the client (browser user or API caller)

Disable automatic Expect: 100-continue behavior in the HTTP client (for example, curl -H "Expect:" or setting ExpectContinue to false).
Send the request body directly without waiting for 100 Continue when talking to servers or proxies known not to support it.
Upgrade the HTTP client library to one with more complete HTTP/1.1 compliance.

If you run the server

Implement proper 100-continue handling per RFC 9110 instead of rejecting the Expect header outright.
Ensure reverse proxies such as nginx or HAProxy pass through or correctly negotiate the Expect header end to end.
Return 100 Continue promptly for expectations the server does support, rather than waiting or erroring.

Example

PUT /uploads/report.pdf HTTP/1.1
Host: api.example.com
Content-Length: 5242880
Expect: 100-continue

HTTP/1.1 417 Expectation Failed
Content-Type: application/json

{"error": "this server does not support 100-continue for this endpoint"}

The client offered a body but the server rejected the Expect header before any body was sent.

Try it live

Our free status responder returns a real HTTP 417 you can point tests, monitors or a browser at.

GET https://mcp.httpstatus.com/status/417