HTTP 411 Length Required explained

The 411 Length Required status is a 4xx client error defined in the HTTP specification. It means the server refused a request because it was missing the Content-Length header that tells the server how many bytes the request body will contain. It is one of the least common status codes in practice, because most clients and servers add this header automatically, but it appears when a hand-written request or a broken proxy chain forgets it.

What it means

For an HTTP request with a body, the client normally sends a Content-Length header giving the exact size of the body in bytes, so the server knows how much to read before the request ends. A 411 response says that the server needs that header and does not have it. The client is allowed to repeat the request, this time including a valid Content-Length.

The usual exception is chunked transfer encoding. When a client sends a body in chunks, it omits Content-Length and instead marks the transfer as Transfer-Encoding: chunked, putting each chunk's length in each chunk. A server that accepts chunked bodies will not return 411 for that format, because the framing is provided differently. A 411 appears when neither Content-Length nor chunked framing is present or recognised.

Common causes

Several situations produce 411, most of them involving nonstandard clients rather than browsers, which handle this correctly:

• A hand-written request or a command-line client that posts a body without a Content-Length header.
• An API client, proxy or load balancer that strips Content-Length, sometimes as a mistaken optimisation or because it reused a connection without adding the updated length.
• A server configured to reject chunked bodies, so a chunked request that lacks Content-Length is turned away with 411.
• A misconfigured reverse proxy that forwards a body without preserving either Content-Length or the chunked transfer header.

Browsers and standard HTTP libraries set these automatically, so a 411 you see in normal web browsing is almost always coming from an API, an upload, an integration between services, or a private request you issued directly rather than a visitor with an ordinary browser.

How to fix it

Approach it by reproducing the exact failing request and inspecting its headers. Use the network panel of the developer tools or a tool that shows raw request headers, and look for whether the body is missing its length.

• If you are calling an API, add the Content-Length header with the byte length of the body, or rely on a library that sets it from the body. For a JSON POST, the length is the number of bytes of the serialised body.
• If a proxy or load balancer sits in front, verify it forwards the length and does not rewrite the request framing. Rebuild the chain and confirm each hop preserves the header.
• If the server rejects chunked bodies, either switch the client to send a fixed Content-Length (by buffering the body) or, if the server owns the behaviour, allow chunked transfer.
• For a hand-written request, the smallest fix is to compute the length and include it. A content length that is wrong, meaning too short or too long, produces a different failure where the connection stalls or the body is truncated, so be sure the number is accurate.

A check after the fix is to repeat the request and confirm it returns the expected success or application-level status rather than 411. If the request still fails, see 400 bad request for the malformed side and 413 payload too large for the server refusing the body once the length is accepted.