HTTP 417 — Expectation Failed
HTTP 417 means the Expect header asked for behaviour the server cannot promise — nearly always Expect: 100-continue hitting a server unwilling to play the two-step dance.
When 417 shows up
- HTTP clients that auto-attach Expect: 100-continue on large bodies.
- Servers and proxies with no interim-response support.
Mocking a 417 response
A response with this status can be faked end to end with a local mock rule — no backend changes needed. The configuration below mirrors the rule fields the ApiSimul editor uses (method, path, status, delay in milliseconds, response body):
{
"method": "GET",
"path": "/api/upload",
"status": 417,
"delay": 160,
"enabled": true,
"body": null
}Dynamic placeholders such as {{random.name}}, {{string.uuid}} or {{number.int 1 100}} can appear inside the body to vary each response, which keeps client-side list rendering and retry logic honest during development.
Frequently asked questions
What does HTTP 417 mean?
The expectation in the Expect header cannot be met. Removing the header or using a server that supports interim responses resolves it.
How can I test a 417 response without a real backend?
Define a mock rule with the method and path your client requests and set the status to 417. The example configuration above returns this response after the listed delay, so the client exercises its 417 handling exactly as it would against a live server.
Related status codes
Need the response in your own project? Spin up rules for any status with the ApiSimul mock server, or browse every status code page.