How would you stop an oversized request body from exhausting a service's memory, and what should the client see?

## Why this is an availability problem, not a validation problem If a framework buffers a request body before anyone checks its size, the worst case is simple arithmetic: **maximum body size multiplied by the number of concurrent in-flight requests**. With no maximum, the product is unbounded, and the cost to the attacker is a slow upload from a single connection. This is why "add a body size limit" appears on every hardening checklist and why the question is asked at senior level — it is an operational control, not input validation. The same arithmetic gives you the number to configure. Decide how much memory the service may devote to in-flight bodies, divide by the concurrency you allow, and that is your cap. A cap chosen without reference to concurrency is a guess. ## Enforce during the read The mechanism that works is a counting read: 1. wrap the body input so every chunk read increments a counter; 2. compare the counter against the cap after each chunk; 3. on the first chunk that crosses it, **stop reading** and raise a limit error; 4. map that error to a response centrally, so every route behaves alike. The property that matters is that the bytes are never all resident at once. A check written as "read the body, then compare its length" performs exactly the allocation the limit exists to prevent, and it is the most common wrong answer to this question. A declared `Content-Length` is a helpful optimisation in front of the counter: when it is present and already exceeds the cap, you can reject before reading a single byte of body. It is not a substitute. The declared length may be absent, and a value on the wire is a claim by the sender rather than something the server has verified. ## Where the limit lives | Layer | What it protects | Typical shape | |---|---|---| | Edge proxy or gateway | the whole fleet, and the network behind it | one generous global cap | | Framework, global | this service's memory and worker pool | the real working limit | | Route override | endpoints that legitimately accept more | narrow, explicit, documented | Configure the layers so the innermost is the one that normally fires, and keep the edge cap at or above it — an edge cap *below* the framework cap produces rejections your service never sees and cannot explain to a caller. Route-level overrides should raise the limit only for the endpoints that need it; a global cap sized for the largest endpoint gives every other endpoint that same exposure. ## Responding without losing the response The status is **413**, the code meaning the body is larger than the server is willing to process. Getting the status right is the easy half. The awkward half is timing: you decide to reject while the client is still sending. If the server writes the response and immediately closes, the client may still be writing, receive a connection reset, and never read the status you carefully chose — the symptom being a client-side "connection reset" where your logs clearly show 413. The mitigations are: - **drain a bounded remainder** of the request before closing, so the client finishes its write and reads the response; - **close deliberately** after the response is flushed, signalling that the connection will not carry more of this request; - **include what the client needs** — the limit that was exceeded — so the caller can fix its request rather than retry it identically. ## Things that make a limit less effective than it looks - **Compressed bodies expand.** A cap applied to the bytes on the wire does not bound the decoded size, so a small compressed body can decode into a very large one. Apply a limit to the decoded stream as well, counted as it is produced. - **Many small bodies still add up.** A per-request cap bounds one request; total exposure is still cap times concurrency, so connection and concurrency limits are part of the same control. - **Slow uploads hold resources.** A body under the cap that trickles in occupies a worker or connection for as long as the client likes, which is why read timeouts belong next to size caps. - **A limit that only exists at the edge is one misroute from irrelevant.** Anything reaching the service directly — internal callers, a health path, a sidecar — bypasses it entirely. - **Silent truncation is worse than rejection.** Reading up to the cap and processing what fits accepts a corrupted request as a valid one. Reject; never truncate. ## What to check when you inherit a service Ask for the configured cap, the maximum concurrency, and the product of the two. If nobody can answer, the service has no bound. Then check that a body over the cap actually produces a 413 in a real client rather than a reset, and that an endpoint accepting large payloads has an explicit override rather than a raised global default.