Why am I getting 411 when my request clearly has a body?

Because the server isn't complaining that the body is missing — it's complaining that you didn't tell it the body's size *in advance*. There are two ways to send a request body in HTTP/1.1: declare a `Content-Length` header with the exact byte count, or use `Transfer-Encoding: chunked` and stream it without a total. A 411 means the server refuses the second option and demands the first. This bites people whose HTTP client streams request bodies by default — some libraries send a chunked upload when you hand them a stream or a generator instead of a fixed buffer. The body is there; the server just won't read it without a length up front, usually because it needs to allocate a buffer or enforce a size cap before accepting a single byte.

Is 411 a client error or a server error? Whose job is it to fix?

It's classified 4xx — a client error — and that classification is correct: the fix is always on the sending side, even though the server chose the policy. [RFC 9110 §15.5.12](https://www.rfc-editor.org/rfc/rfc9110#section-15.5.12) is explicit that the server MAY reject a request that lacks a `Content-Length`, and that the client can repeat the request with the header added. So the server is within its rights, and there's nothing to 'fix' on it beyond deciding whether you want to accept chunked request bodies at all. On the client, the fix is mechanical: buffer the whole body, measure its length in bytes, and send it with an explicit `Content-Length`. You can't argue a 411 away by retrying the same chunked request — you have to change how the request is framed.

How is 411 different from 413 or 431?

All three are the server rejecting your request before processing it, but for opposite reasons, and mixing them up sends you down the wrong path. 411 Length Required means you sent *no* length and the server insists on one — the problem is a missing header, and the fix is to add `Content-Length`. 413 Content Too Large means you sent a length (or a body) that *exceeds* a limit — the fix is to shrink the payload or raise the server's cap, not to add a header. 431 Request Header Fields Too Large is about the *headers*, not the body — too many cookies, an oversized JWT. So 411 is 'tell me the size,' 413 is 'that size is too big,' and 431 is 'your headers are too big.' Only 411 is solved by adding information rather than removing it.

Views: 23

411 Length Required: Add a Content-Length

411 Length Required means the server rejected a request with no Content-Length. Buffer the body, set the length, resend. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

You send a POST or PUT and the server bounces it with 411 Length Required before doing any work. The body is right there in your request — but the server won’t touch it. It isn’t objecting to what you sent; it’s objecting to what you didn’t declare: the size of the body, up front, as a Content-Length header.

Symptoms

A POST/PUT/PATCH returns 411 immediately, with no application-level error.
The same call works from curl or Postman but fails from your code (or vice versa).
It happens on streamed or chunked uploads — piping a file, a stream, or a generator into the request body.
Some clients hit it on an empty-body POST (a form submit or webhook with nothing to send).
The failing requests carry Transfer-Encoding: chunked instead of Content-Length.

What This Error Actually Means

HTTP/1.1 gives you two ways to frame a request body. You can send Content-Length: 4096 and then exactly 4096 bytes — a fixed, known size. Or you can send Transfer-Encoding: chunked and stream the body in pieces, terminated by a zero-length chunk, without ever committing to a total. The chunked form exists precisely so you can start sending before you know how much there’ll be.

RFC 9110 §15.5.12 defines 411 as the server’s refusal to take the second option: it “refuses to accept the request without a defined Content-Length.” The server wants to know the size before it reads a byte — usually so it can pre-allocate a buffer, enforce a maximum request size, or hand the body to something (a legacy handler, a strict WAF, a storage API) that can’t cope with a stream of unknown length.

The word that matters is defined. This isn’t about a body being empty or malformed. It’s about the server declining to accept a body whose length it can’t see in advance. The RFC is equally explicit about the cure: the client “MAY repeat the request if it adds a valid Content-Length header field.” So a 411 is not a dead end — it’s a specific instruction. Buffer the thing, count the bytes, tell the server the number.

Top 3 Causes

Your HTTP client is streaming the body as chunked. This is the common one. Hand many HTTP libraries a file object, a stream, or a generator as the request body and they’ll default to Transfer-Encoding: chunked rather than reading the whole thing to compute a length. Against a server that requires Content-Length, every one of those uploads 411s. The tell: it works when you pass a fixed string or byte buffer and fails when you pass a stream.
An empty-body POST with no length header. Some clients omit Content-Length entirely when there’s no body to send — a bare form submission, a webhook ping, a POST used as a trigger. A strict server reads “no Content-Length, no chunked encoding” as “I can’t tell where this request’s body begins or ends” and returns 411. The fix is a single header: Content-Length: 0.
A strict server or middlebox that rejects chunked request bodies. Older IIS setups, some Java servlet containers, certain object-storage endpoints, and hardened WAFs refuse chunked requests on purpose — they want a length so they can enforce limits before buffering. Your client is behaving reasonably; the server has simply opted out of the streaming path, and it’s telling you so with 411.

Diagnose with DechoNet

HTTP Check confirms the response is genuinely a 411 from the origin and not a 400 or 413 you’ve misread — the three get conflated constantly, and they have opposite fixes. Seeing the exact status code and the response headers is the first step before you touch your client.
The check shows the response headers, so you can see whether a proxy, CDN, or WAF is in the path. A 411 that appears only when a request transits a particular edge points at a middlebox policy, not your origin — worth knowing before you rewrite your upload code.

Resolution Checklist

Confirm it’s really 411, not 413 (too large) or 431 (headers too big). The fix diverges completely: 411 means add a length; 413 means shrink the body; 431 means trim headers.
Send a Content-Length instead of chunked. In your HTTP client, buffer the body fully, measure its byte length, and set the header explicitly. Concretely: read the file/stream into a string or byte array before sending, rather than handing the client a stream it will chunk.
For empty POSTs, set Content-Length: 0. If the request legitimately has no body, say so with an explicit zero-length header rather than omitting it.
Check the library’s streaming behavior. Many clients switch to chunked automatically for stream/generator bodies. Pass a fixed buffer, or use the client’s option to compute and send a length.
If you control the server and don’t want this, decide whether to accept chunked request bodies. Some stacks let you enable it; the trade-off is that you lose the ability to enforce a size limit before buffering.
Re-test through the same path. If a WAF or proxy is imposing the 411, verify your fix against the real edge, not just a direct-to-origin call.

When to Escalate

If your client is already sending a correct Content-Length and you still get 411, escalate to whoever runs the proxy or WAF in front of the service — a middlebox may be stripping or rewriting the header before it reaches the origin, and only their logs will show it.
If a third-party API returns 411 for a documented streaming upload, check their docs for a required Content-Length (or a multipart/resumable alternative) before assuming a bug — many storage APIs deliberately require a declared size and offer a separate chunked-upload protocol of their own.