Maximum request-body size, in bytes, enforced where the body is read. Omitted, the read is unbounded — the released behaviour, byte for byte.

This is the layer no request header can switch off. HttpSecurityPlugin({ requestSize: { maxBodySize } }) refuses on a DECLARED Content-Length before anything is read, which is cheaper and reports earlier — but a chunked request declares no length, and since M87 made the body lazy the read happens inside the handler, after every middleware has returned. So a chunked body can only be bounded here.

The two knobs exist because the mapping runs before any plugin and there is no channel between them: mapWebRequestToFrameworkRequest receives a Request and nothing else. Set both, and set this one to the same value or higher.

A body past the cap rejects with RequestBodyTooLargeError, branded with a 413 status hint, so an application running errorHandler answers 413 Payload Too Large in its configured format. With no errorHandler registered the brand has no reader and the kernel's opaque 500 answers instead, which is how every other status hint behaves.

0 means "refuse every request that carries a body", not "disabled" — unlike maxDepth, maxNodes, maxBatchSize and documentCacheSize elsewhere in this framework, where 0 disables the check. Omit the option for unbounded; there is exactly one way to say that. A value that is not a non-negative integer — a negative, a fraction, or the NaN that Number(env.MAX_BODY_BYTES) yields for an unset or misspelled variable — throws here rather than being accepted: NaN would make every comparison against the cap false and silently disable the bound, which is the one failure a size limit must not have.