Skip to content
ENPT

HTTP status code · Client errors (4xx)

411 Length Required

411 Length Required means the server will not accept the request unless it declares its body size in a Content-Length header. It is almost always a POST or PUT with an empty body, or an upload sent with chunked transfer encoding.

Facts about this status code
Class4xx, Client errors
Defined inRFC 9110 §15.5.12
Cacheable by defaultOnly with explicit Cache-Control or Expires
Safe to retryYes, once the request carries a valid Content-Length
Relevant headers
  • Content-Length: request header the server insists on; use Content-Length: 0 for an empty body
  • Transfer-Encoding: chunked uploads have no length up front, which is what some servers reject

What 411 means

RFC 9110, section 15.5.12, says the server refuses the request without a defined Content-Length, and that the client may repeat it once it adds one. Servers do this when they want to check the size before reading anything, or when they sit on an HTTP/1.0 path that cannot handle chunked bodies.

The classic example is Google: a POST to many Google endpoints without Content-Length returns a 411 page saying POST requests require a Content-length header. HTTP/2 and HTTP/3 frame the body themselves, so the error is mostly an HTTP/1.1 phenomenon.

Common causes

If you run the server

  • A client sends POST or PUT with no body at all, as curl -X POST does without -d, and omits Content-Length.
  • An HTTP client streams the body with Transfer-Encoding: chunked (Node streams, Java HttpURLConnection in chunked mode) to a server or proxy that requires a length.
  • A load balancer or legacy proxy in front of your app rejects chunked requests even though the app would accept them.

How to fix it

If you run the server

  • For an empty body, send Content-Length: 0 explicitly (curl -d "" or -H "Content-Length: 0").
  • For uploads, buffer the body or compute its size first so the client can set Content-Length instead of streaming chunks.
  • If you control the server, accept chunked bodies unless you have a reason not to; enforce size with a body limit instead.

How to send 411

Express (Node.js)
app.post('/ingest', (req, res, next) => {
  if (req.get('Content-Length') === undefined) {
    return res.status(411).json({ error: 'Content-Length header required' });
  }
  next();
});
Go net/http
mux.HandleFunc("POST /ingest", func(w http.ResponseWriter, r *http.Request) {
	// ContentLength is -1 when the client streamed a chunked body
	if r.ContentLength == -1 {
		http.Error(w, "Content-Length header required", http.StatusLengthRequired) // 411
		return
	}
	// ...
})
Shell
# Fails on servers that require a length
curl -X POST https://api.example.com/ingest

# Works: an explicit empty body sets Content-Length: 0
curl -X POST -d '' https://api.example.com/ingest

Commonly confused with

411 vs 413
413 means the declared or actual body is too big; 411 means the size was not declared at all.
411 vs 400
400 is a general malformed request; 411 pinpoints the one missing header.

Frequently asked questions

Why does an empty POST get 411?
Without a body, some clients omit Content-Length entirely, and the server cannot tell an empty body from one that has not arrived yet. Sending Content-Length: 0 removes the ambiguity.
Does 411 happen over HTTP/2?
Rarely. HTTP/2 and HTTP/3 mark the end of the body with frame flags, so a length header is not needed to find the end. You mostly see 411 on HTTP/1.1 connections or behind proxies that downgrade to HTTP/1.1.
Can I retry a request that got 411?
Yes. RFC 9110 explicitly allows the client to repeat the request after adding a valid Content-Length header.

Last reviewed by Arielton Oberek.