HTTP 411 Length Required

Quick reference

Content-Length vs chunked transfer encoding

HTTP/1.1 allows two ways to send a request body:

Content-Length: The client declares the exact byte count of the body upfront. The server reads exactly that many bytes and knows the request is complete. The body must be fully assembled before the request starts.

POST /api/upload HTTP/1.1
Content-Type: application/json
Content-Length: 47

{"filename": "report.pdf", "size": 2048576}

Chunked transfer encoding: The body is sent in pieces. Each chunk is prefixed with its hex size. A zero-size chunk signals the end. The total body size is unknown until the last chunk arrives.

POST /api/upload HTTP/1.1
Content-Type: application/json
Transfer-Encoding: chunked

1e
{"filename": "report.pdf",
1b
 "size": 2048576}
0

A server returning 411 is saying: “I require Content-Length. I will not accept chunked encoding or a body without a declared size.”

Why servers require Content-Length

Memory pre-allocation: Some servers allocate a buffer for the request body before reading it. With Content-Length, they can allocate exactly the right amount. Without it, they must either use dynamic allocation (more complex) or reject the request.

Size limit enforcement before reading: A server that enforces a maximum body size (e.g., no uploads over 10MB) can check Content-Length before reading a single byte of the body. Without Content-Length, the server must read the entire body before discovering it exceeds the limit — wasting bandwidth and processing time.

Legacy HTTP/1.0 infrastructure: HTTP/1.0 did not support chunked transfer encoding. Proxies, load balancers, or servers that operate at HTTP/1.0 semantics require Content-Length. Some corporate proxies, legacy reverse proxies, and certain hardware appliances fall into this category.

Explicit policy: Some APIs explicitly require Content-Length for audit, rate-limiting, or verification purposes. The response from a 411 should indicate what the requirement is.

How to fix 411

Add Content-Length with the exact byte count of the request body. Important: byte count, not character count. For ASCII content they are the same; for UTF-8 text with non-ASCII characters, a single character may be 2–4 bytes.

Python:

import requests, json

payload = {"filename": "report.pdf", "size": 2048576}
body = json.dumps(payload).encode("utf-8")  # bytes, not str

response = requests.post(
    url,
    data=body,
    headers={
        "Content-Type": "application/json",
        "Content-Length": str(len(body))  # exact byte count
    }
)

curl: curl automatically sets Content-Length for most request types. If you are streaming and see 411, use -d @file instead of piping stdin, or explicitly set the header:

curl -X POST   -H "Content-Type: application/json"   -H "Content-Length: $(wc -c < body.json)"   --data-binary @body.json   https://api.example.com/upload

JavaScript fetch: For string and Blob bodies, fetch sets Content-Length automatically. For ReadableStream bodies, it uses chunked encoding. Convert to a Blob or string if the server requires Content-Length:

const body = JSON.stringify(payload);
const response = await fetch(url, {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "Content-Length": new TextEncoder().encode(body).length.toString()
  },
  body: body  // string body, Content-Length set above
});

Node.js http module:

const body = JSON.stringify(payload);
const options = {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "Content-Length": Buffer.byteLength(body)  // Buffer handles encoding
  }
};
const req = https.request(url, options, callback);
req.write(body);
req.end();

Server-side configuration

If you control the server and want to require Content-Length (while rejecting chunked encoding):

nginx: nginx accepts chunked encoding by default. To reject it and require Content-Length, use the chunked_transfer_encoding off directive (this affects responses, not requests). For request body handling, nginx’s behavior with missing Content-Length depends on the upstream configuration. Explicitly requiring Content-Length in nginx requires a custom Lua module or checking in application code.

Express.js: Return 411 explicitly when Content-Length is absent on endpoints that require it:

app.post("/api/upload", (req, res, next) => {
  if (!req.headers["content-length"]) {
    return res.status(411).json({
      error: "length_required",
      message: "Content-Length header is required"
    });
  }
  next();
});

411 vs related codes

Frequently asked questions

What causes HTTP 411?

The server received a request with a body but no Content-Length header. This typically happens when an HTTP client uses chunked transfer encoding or streaming for the request body, and the server does not support or refuses chunked encoding for requests.

Does modern HTTP require Content-Length?

No. HTTP/1.1 and HTTP/2 both support chunked encoding or framing that makes Content-Length optional for request bodies. Requiring Content-Length is a server policy decision, not an HTTP/1.1 requirement. A 411 is the server enforcing its own stricter requirement.

Why does curl sometimes send without Content-Length?

curl uses chunked transfer encoding when the body size is not known in advance, such as when reading from stdin or a pipe. Use -d @filename instead of stdin piping, or add an explicit -H "Content-Length: $(wc -c < file)" override.

Is Content-Length the byte count or character count?

Byte count, not character count. For ASCII content they are identical. For UTF-8 text with multi-byte characters (accented letters, non-Latin scripts, emoji), use the byte length of the encoded string, not the number of Unicode characters.

Related guides

HTTP 413 Content Too Large · HTTP 400 Bad Request · HTTP 417 Expectation Failed

Standards reference

Definitions from the IANA HTTP Status Code Registry and RFC 9110 §15.5.12. Human-readable guidance by ErrorLookup. · HTTP 411 quick reference →