No actionable comments were generated in the recent review. 🎉

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

Open in StackBlitz

npm i https://pkg.pr.new/srvx@216

commit: afbec2b

Follow-up: hot-path allocation fix + Bun/Deno default comparison

Perf fix (pushed): The initial commit changed runtime.node from reusing the passed context object to allocating a fresh { req, res } literal per request (to keep maxBodySize off the public shape). Benchmarking showed this added ~4–5 ns to every request on the hot path, even with no limit configured. The follow-up commit reverts to node: ctx — maxBodySize rides along but is intentionally excluded from the public runtime.node type, and all consumers only read req/res. Measured constructor cost is now ~25 ns/ctor, identical to main (within noise). The per-chunk readBody guard was already correctly skipped when maxBodySize is unset, so the default path is now truly zero-overhead.

Do other runtimes impose a default?

So there's precedent (Bun) for a safe default, but Deno and raw Node have none. Left as undefined (opt-in) here because this limit currently only covers the buffered .text()/.json() fallback — streaming (request.body) is unaffected — so a default-on limit would apply asymmetrically and could surprise streaming apps. If a default is desired for parity with Bun, 128 MiB would match, but I'd suggest deciding that separately from this guard mechanism.

Update: maxBodySize now covers all body-read paths + toNodeHandler

The initial commit only enforced the limit in the buffered readBody() fallback (text()/json()). Reads that route through the native Request — arrayBuffer(), blob(), bytes(), formData() — and direct streaming of request.body bypassed it, which meant the most common heavy path (multipart file uploads via formData()) was uncapped.

c41c1bc closes that gap by enforcing at the single choke point every consumer funnels through: request.body's ReadableStream is wrapped with a pull-based limiter that counts bytes and errors with the same 413-style error (ERR_BODY_TOO_LARGE, statusCode: 413) once exceeded, cancelling the upstream Node stream. Because it's pull-based it preserves backpressure and stops reading as soon as the limit is hit rather than buffering first. The readBody() fast path keeps its own cheap check.

Verified end-to-end that arrayBuffer(), bytes(), blob(), formData(), streaming, and text()/json() all return HTTP 413 with the limit set, and within-limit requests still succeed. Tests expanded to 9 (per-method + multipart + within-limit + backward-compat); full node suites pass (145 passed / 6 skipped).

Hot path unchanged: when maxBodySize is undefined (default) the body stream is not wrapped — no overhead. Combined with 8f2bc6a (reuse the request context object), the default path has zero added allocation vs main.

Also threaded through toNodeHandler(handler, { maxBodySize }) so handlers embedded in an existing Node server can opt in. Still Node-only; other runtimes ignore the option (docs updated to say "Currently only enforced for the Node.js runtime").

Update: maxBodySize is now a cross-runtime option (Bun + Deno)

Promoted maxBodySize from Node-only to a generic server option, enforced on every runtime srvx can enforce it on:

• Extracted the body-limit primitives into a runtime-agnostic module src/_body-limit.ts — createBodyTooLargeError, limitBodyStream (used by the Node body getter), and limitRequestBody (rebuilds a native Request with a size-limited body, preserving method/url/headers/signal).
• Bun: mapped to Bun's native maxRequestBodySize — Bun returns 413 before the handler runs. An explicit bun.maxRequestBodySize still wins. (Bun's own default is 128 MiB; srvx leaves it unset unless you set maxBodySize.)
• Deno: Deno.serve has no native body-size option, so srvx enforces it in the fetch wrapper by rebuilding the request with a limited body stream. No-op when unset or bodyless, so the default hot path is unchanged.
• Node: unchanged (srvx stream limiter + fast-path readBody check).

Docs updated to a per-runtime support table.

Verified end-to-end on all three runtimes (413 over the limit, 200 within), with automated tests: Node via vitest (9 cases), and Bun/Deno via spawned fixtures (test/bun-max-body-size.test.ts, test/deno-max-body-size.test.ts, sharing test/fixtures/max-body-server.ts). Full suites green: node/bun/deno adapter suites + all body-size tests (191 passed / 8 skipped).