Why is checking r.ContentLength not a safe size cap on an untrusted HTTP request body in Go?

## What r.ContentLength actually is On a server-side `*http.Request`, `ContentLength` is an `int64` populated from the incoming `Content-Length` header. Its documented values matter: - **A non-negative number** — the client declared a body of that many bytes. - **`-1`** — the length is unknown. This is what a request using chunked transfer encoding gives you: the body arrives as a sequence of chunks and the total is not known until the last one is read. - **`0`** — there is no body. So `ContentLength` is a *claim about* the body, made in the headers, available before a single body byte has been read. That is exactly why it looks like an attractive place to enforce a limit, and exactly why it does not work as one. ## The hole Write the natural check: ```go if r.ContentLength > maxBody { http.Error(w, "body too large", http.StatusRequestEntityTooLarge) return } ``` A poster who wants to send you an unbounded body simply does not declare a length. `ContentLength` comes back as `-1`, `-1 > maxBody` is false, and the request sails straight through to the decoder that will read until the sender stops sending. The check is not merely incomplete: it is bypassed by choosing a request encoding, which costs an attacker nothing. A public webhook receiver with this guard has, in practice, no body cap. ## The second, subtler problem Even for a request that *does* declare a length, the header check happens in a different place from the cost. The memory your handler allocates comes from the bytes it reads, so the limit belongs on the read path. Enforcing on the header means the limit is only as good as the correspondence between what was declared and what is read — a correspondence you are asserting rather than enforcing. `http.MaxBytesReader` enforces it: it counts the bytes that actually pass through, and fails the read that crosses the line, no matter what any header said. ## What to do instead Cap the reader, and treat the header as an optimisation: ```go if r.ContentLength > maxBody { // fast path; -1 falls through http.Error(w, "body too large", http.StatusRequestEntityTooLarge) return } r.Body = http.MaxBytesReader(w, r.Body, maxBody) ``` The first check is worth having: when a client honestly declares 500 MB you can reject in microseconds without reading anything, which is real protection against wasted bandwidth and time. But it is a courtesy, not the defence. The wrapper is the defence, and it is the one that must never be optional. Because `-1` falls through the comparison, the two compose correctly: declared-and-huge is rejected early, undeclared or under-cap is read through the cap. ## Where this bites in review The misconception shows up in three recognisable forms. The first is the header-only guard above. The second is a handler that reads the body into a buffer sized from `ContentLength` and assumes the read cannot exceed it — sizing from an attacker-supplied number is its own problem, since `-1` is not a size and a large declared value is a free allocation request. The third is a middleware that logs or meters `ContentLength` and treats a `-1` as zero, which quietly under-reports exactly the traffic that is unbounded. ## The mental model Headers describe intent; readers observe reality. Any limit that protects memory has to sit on the path where memory is spent. `ContentLength` is a useful hint for fast rejection, for metrics, and for deciding whether to stream to disk rather than buffer — but a hint from an untrusted party is never the enforcement point.