feat: export body size limit helpers via srvx/body-limit#280
Conversation
Make the runtime-agnostic body-size-limit utilities public so downstream layers (e.g. h3 per-handler limits) can reuse the same streaming semantics and error shape. Closes #279. - Rename `_body-limit.ts` -> `body-limit.ts` and add `./body-limit` export - Type body streams as `ReadableStream<Uint8Array>` - Reject early (without reading the body) when `Content-Length` already exceeds the limit, keeping the streaming limit as the source of truth - Document pull/backpressure semantics and the canonical 413 error shape - Add `srvx/body-limit` guide page and unit tests Co-Authored-By: Claude Opus 4.8 <[email protected]>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (3)
📝 WalkthroughWalkthroughThe change exposes runtime-agnostic body-size limiting helpers through ChangesBody-limit helper export
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related issues
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
commit: |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/body-limit.ts`:
- Around line 93-99: The fast-path check in the body-size enforcement flow must
only use a syntactically valid, all-digit Content-Length value. Update the
contentLength parsing around request.headers.get("content-length") to validate
the raw header before numeric conversion, treating malformed, decimal,
hexadecimal, Infinity, empty, or absent values as unavailable so they fall
through to streaming enforcement; retain early rejection only for valid values
exceeding maxRequestBodySize.
- Around line 20-24: Define and export a BodyTooLargeError type containing the
documented code, statusCode, and status fields, then update
createBodyTooLargeError to return that type instead of the generic Error.
Preserve the existing error message and field values while exposing the complete
shape to TypeScript consumers.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: b6e3df18-25e8-4118-b09c-753d0c68298d
📒 Files selected for processing (9)
build.config.mjsdocs/1.guide/11.body-limit.mddocs/1.guide/5.options.mdpackage.jsonsrc/_body-limit.tssrc/adapters/_node/request.tssrc/adapters/deno.tssrc/body-limit.tstest/body-limit.test.ts
💤 Files with no reviewable changes (1)
- src/_body-limit.ts
- Export a typed `BodyTooLargeError` interface so consumers get the `code`/`statusCode`/`status` fields without casting - Only fast-reject on an all-digit `Content-Length` (HTTP `1*DIGIT`); treat decimal/hex/`Infinity`/malformed values as absent and fall through to the authoritative streaming limit Co-Authored-By: Claude Opus 4.8 <[email protected]>
…d content-length Co-Authored-By: Claude Opus 4.8 <[email protected]>
Closes #279.
Exposes srvx's runtime-agnostic body-size-limit utilities as a public
srvx/body-limitsubpath so downstream layers (e.g. h3 per-handler limits) can enforce the same streaming semantics and error shape instead of re-implementing them.Changes
src/_body-limit.ts→src/body-limit.ts(public); add the./body-limitexport + build input. Internal Node/Deno adapter imports updated.ReadableStream<Uint8Array>typing onlimitBodyStream.Content-Lengthrejection inlimitRequestBody— rejects without reading a byte when the declared size already exceeds the limit.{ code: "ERR_BODY_TOO_LARGE", statusCode: 413, status: 413 }.srvx/body-limitguide page + cross-link from themaxRequestBodySizeoption doc.test/body-limit.test.ts).Design note: early rejection
The naive "throw synchronously from
limitRequestBody" would regress the Deno adapter — the throw escapes the fetch wrapper before the handler'stry/catchand turns a clean 413 into an uncaught 500. Instead the returned request's body stream is pre-errored (and the original body cancelled unread). This still avoids reading any bytes off the socket, but the error surfaces on consumption — identical to the streaming path — so every existing caller works unchanged.Content-Lengthis treated strictly as a fast path; the streaming limit remains the source of truth (absent/understated headers under chunked encoding are still caught).Verification
pnpm lint,pnpm typecheck, and fullvitest run(1262 passed / 35 skipped) — including the real-runtime Deno end-to-end body-limit test, which exercises the new early-reject path.🤖 Generated with Claude Code
Summary by CodeRabbit
srvx/body-limitsubpath export.ERR_BODY_TOO_LARGEHTTP 413-style error.Content-Length, and malformedContent-Lengthhandling.