HTTP 417 Expectation Failed – Free, Online, Private

What HTTP 417 means

417 says an expectation in the request, almost always Expect: 100-continue, cannot be met. The server will not send 100, and the client should not send the body it was holding. Other expectation values are rare and are defined as failures if the server does not understand them. A server that simply ignores Expect and reads the body does not send 417.

417 Expectation Failed belongs to the 4xx client error class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 417

When you see HTTP 417 Expectation Failed, stop on that exact status line. 417 Expectation Failed means the server cannot meet the Expect header. The trace that usually produces it: Expect: 100-continue was sent and the server refuses that handshake. The 4xx client error class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

Return 417 when you will not honor Expect. If the headers are unacceptable for a reason of their own, you may skip 100 and send the real 4xx instead, which is often more useful than 417. Use 417 when the expectation itself is the problem. Do not use it for a failed business rule.

How to fix HTTP 417

To fix HTTP 417, change the condition that made the server choose Expectation Failed. Do not send the pending body after 417. Either stop or retry without Expect. Do not loop on 100-continue against a server that has refused it. A retry without the Expect header is reasonable once. A retry with the same Expect is not. If the log line is a different code, leave this page. The mix-up people make with 417 is this one: 100 Continue is the success path for Expect. 417 is the refusal. 412 is a different word and a different header family: preconditions, not expectations.

• A proxy did not understand Expect and returned 417 before the origin saw the request.
• A client treated 417 as a reason to send the body anyway and the server closed the connection.
• An API used 417 for a failed assertion in application code, which clients read as an HTTP expectation problem.

An access log that only stores 417 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

HTTP 417 Expectation FailedHTTP/1.1 417 Expectation Failed

The client should not continue with the body it was waiting to send. It may retry without the Expect header if the server is likely to accept the request itself. If the 417 is standing in for a 401, the retry without Expect will just get the 401, which is a better error.

What the client should do

Do not send the pending body after 417. Either stop or retry without Expect. Do not loop on 100-continue against a server that has refused it.

Do not cache 417. It is about one request's expectations.

A retry without the Expect header is reasonable once. A retry with the same Expect is not.

Codes people confuse with HTTP 417

100 Continue is the success path for Expect. 417 is the refusal. 412 is a different word and a different header family: preconditions, not expectations.