HTTP 411 Length Required
HTTP 411 Length Required means the server will not process the request unless the client includes a Content-Length header indicating the exact size of the request body. The server needs to know how much data to expect before it begins processing.
411 is relatively rare on modern APIs and web servers, but it appears regularly in strict server configurations, older proxy servers, and certain CDN edge environments that enforce header validation.
Quick reference
| Code | 411 |
|---|---|
| Name | Length Required |
| Category | 4xx Client Errors |
| Specification | RFC 9110 §15.5.12 |
| IANA status | Assigned |
| Client behavior | Resend the request with a Content-Length header containing the exact byte length of the request body. |
| Caching | Not cached. |
| In-depth guide | HTTP 411 Content-Length guide → |
What it means
When a client sends a POST, PUT, or PATCH request, the server needs to read and process the request body. The Content-Length header tells the server exactly how many bytes to expect. Without it, the server either has to buffer the entire request before processing (memory-intensive), detect the end of the body through framing (complex), or refuse the request entirely.
HTTP/1.1 introduced Transfer-Encoding: chunked as an alternative to Content-Length, allowing streaming requests where the total size is not known upfront. A server that returns 411 is explicitly saying it does not support chunked transfer encoding and requires the body size to be declared in advance.
HTTP/2 and HTTP/3 handle message framing differently and rarely produce 411 errors. 411 is primarily an HTTP/1.1 issue encountered with older servers, strict proxy configurations, and certain API gateways.
Content-Length vs Transfer-Encoding: chunked
RFC 9110 specifies that a sender should use either Content-Length or Transfer-Encoding: chunked, not both simultaneously. When a server returns 411, it means it will not accept chunked encoding and requires Content-Length instead. The client must compute the full body size before sending, which is straightforward for static payloads but requires buffering for streaming scenarios.
Common causes
HTTP client omitting Content-Length
Some HTTP client libraries default to chunked transfer encoding for streaming requests and only include Content-Length when explicitly set. If the server requires Content-Length and the client is using chunked encoding, the result is 411.
Streaming request body without known length
Reading from a stream (file, stdin, pipe) into a request body sometimes means the total length is not known until the stream is fully read. If Content-Length is omitted and the server requires it, the request fails with 411. Buffer the full body first to compute the length, then send with Content-Length.
Proxy stripping headers
An intermediate proxy may strip Content-Length headers and convert to chunked encoding without the origin server expecting it. If the origin requires Content-Length, requests through such a proxy will receive 411 at the origin.
CDN or API gateway enforcement
Some CDNs and API gateways enforce Content-Length presence as a security measure to prevent certain HTTP request smuggling attack vectors. In these cases, 411 is an intentional security policy rather than a server limitation.
How to fix a 411 error
- Add a Content-Length header. Calculate the exact byte length of the serialized request body and include it as
Content-Length: N. In most programming languages: Python —len(body.encode('utf-8')), JavaScript —Buffer.byteLength(body), Go —len([]byte(body)). - In curl, use -d or --data. When you specify a body with
-d, curl automatically computes and includes Content-Length. Using--data-binary @filealso sets Content-Length based on file size. - Buffer streaming requests. If your request body comes from a stream, read the entire stream into memory first, compute the length, then send the request. This is the tradeoff: you lose streaming efficiency but satisfy the server's requirement.
- Check for proxy header modification. If requests work directly but fail through a proxy, the proxy may be stripping or modifying Content-Length. Bypass the proxy for that request or configure the proxy to preserve the header.
411 vs 413 vs 400
| Code | Problem | Fix |
|---|---|---|
| 411 | Content-Length header missing | Add Content-Length header with exact byte count |
| 413 | Request body is too large | Reduce body size or increase server limits |
| 400 | Malformed request syntax | Fix the request format |
See also: 411 vs 413 comparison
FAQ
What does HTTP 411 mean?
HTTP 411 Length Required means the server requires a Content-Length header and the client did not include one. The server will not process the request body without knowing its size in advance.
When do servers return 411?
For POST, PUT, or PATCH requests that omit Content-Length and either do not use chunked transfer encoding or use it in a way the server does not support. Common in strict proxy configurations and some API gateways.
How do I fix a 411 error?
Add a Content-Length header with the exact byte length of the request body. In curl, use -d or --data and curl will set it automatically.
Does 411 apply to GET requests?
No. 411 only applies to requests with a body (POST, PUT, PATCH, and sometimes DELETE). GET and HEAD requests do not have request bodies and will not trigger 411.
Related resources
On this site: HTTP 411 Content-Length guide · HTTP 410 Gone · HTTP 413 Content Too Large · HTTP 400 Bad Request · HTTP 431 Request Header Fields Too Large · All 4xx client errors
Comparisons: 411 vs 413
Standards: RFC 9110 §15.5.12 · IANA Registry · MDN Web Docs: 411