Quick answer: A 411 Length Required means the server rejected a request because it needs a Content-Length header. It often happens when a client streams the body with Transfer-Encoding: chunked and the server or a proxy does not accept chunked requests. Inspect the raw headers, then buffer the body and send an explicit Content-Length, or send Content-Length: 0 for an empty body.
What the status code means
HTTP gives a client two ways to frame a body. When the size is known, the client sends Content-Length with the byte count; when the body is streamed and its size is unknown, it sends Transfer-Encoding: chunked, breaks the body into chunks, and ends with a zero-size chunk. Both are valid, but not every server accepts both.
A 411 is the server saying it will not read the body without a Content-Length. The failure happens at the framing layer before the payload is parsed, so the body content is not the problem; even valid JSON can return 411 because the server never reads it.
Why chunked input triggers it
Chunked transfer is usually produced by streaming clients, code that pipes a file or generator, and HTTP libraries that switch to chunked encoding when no length is supplied. Some servers, and proxies in front of them, require a known length and answer 411 when they see a chunked request.
A second case is a POST or PUT with an empty body and no headers at all; the server treats the missing length as ambiguous rather than zero bytes and returns 411. A proxy can also cause this, because framing headers are hop-by-hop and an intermediary may strip or rewrite Content-Length as it forwards the request.
How to inspect the request
Capture the raw request headers rather than guessing from the client code. Confirm whether the request carries Content-Length, Transfer-Encoding, or neither. If Transfer-Encoding is present, the server is likely declining chunked framing; if neither is present on a body-bearing request, supply a length.
Reproduce the call with a command-line client to see the exact framing, and check any proxy in the path for rules that alter these headers. Do not send Content-Length and Transfer-Encoding together, since they describe the same body in conflicting ways.
Symptoms, causes, and fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| 411 on a streamed upload | Server rejects chunked requests | Buffer the body and send Content-Length |
| 411 on an empty POST | No framing header at all | Send Content-Length: 0
|
| Works direct, fails through a proxy | Proxy strips or rewrites framing | Fix the proxy rule or set length before it |
| Body is valid but still 411 | Framing rejected before parsing | Correct the header, not the payload |
| 411 only for large or piped bodies | Library switches to chunked | Precompute size and set Content-Length |
Fixing the client
If the server requires a length, buffer the body so its size is known, set Content-Length to the exact byte count, and drop the chunked header. For an empty request, send Content-Length: 0; when a proxy is involved, set the framing before it reaches the proxy and verify the header survives.
Buffering trades memory for compatibility, so keep streaming only for backends that accept chunked input. If the server supports chunked but a gateway does not, fix the gateway.
Verify with a real request
After the change, send the real request and assert the status is 200 rather than 411. A scenario can run the call as an ordered step, assert the status and headers, and keep the evidence. For offline work, a local mock can return 411 for chunked framing and 200 once Content-Length is present while recording requests, so you confirm the framing without touching the live service.
The mock models your client behavior, not the real server's rules, so the final check is still a live request. Powerduck sends these requests through the local main process without browser CORS limits, runs status and header assertions at each step, and can record mock traffic. For more, see the API debugging guide hub.
Honest limits
A green scenario proves that one request now carries accepted framing; it does not prove every proxy preserves the header, and a mock cannot reproduce every gateway's rewriting. Keep the live check as the source of truth, and if a verification script is missing, mark that step unverified rather than passed.
Frequently asked questions
Is chunked encoding wrong? No, it is valid HTTP for streaming bodies, but some servers and proxies require a known length; the 411 tells you which side you are on.
Why does an empty POST get a 411? Without a header the server cannot tell zero bytes from a missing body, so Content-Length: 0 removes the ambiguity.
The bottom line
A 411 is a framing mismatch: the client sends chunked or no length, while the server requires Content-Length. Inspect the raw headers, buffer the body and set an exact length, or send Content-Length: 0 for an empty body, and check proxies that rewrite hop-by-hop headers. Confirm the fix with a scenario and a live request, and the 411 stops coming back.
Top comments (0)