feat(readBody): support formdata type#1164
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
| const text = await event.req.text(); | ||
| const contentType = event.req.headers.get("content-type") || ""; | ||
|
|
||
| if (contentType.startsWith("multipart/form-data")) |
There was a problem hiding this comment.
We should make it opt-in by supporting event, opts?: { type: "json" | formData" } and throw an HTTPError if it is not.
There was a problem hiding this comment.
We should make it opt-in by supporting
event, opts?: { type: "json" | formData" }and throw an HTTPError if it is not.
i support this. but my changes remain valid, right? since opts is optional. when you specify type in opts, you're specifying a certain body type, when you're not, you're parsing any body as an object or string!
There was a problem hiding this comment.
As security measure we should make types opt-in other than JSON (so if no options only json)
|
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 (4)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (3)
📝 WalkthroughWalkthrough
ChangesreadBody multipart handling
Estimated code review effort: 3 (Moderate) | ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 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 |
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/utils/body.ts`:
- Around line 30-31: The multipart form parsing branch in the body utility is
missing the same error handling used by the JSON path. Update the body parsing
logic around the event.req.formData() call to wrap malformed/truncated multipart
failures in a try/catch and throw a consistent HTTPError 400, matching the
existing JSON handling in the same helper so bad payloads don’t surface as
unhandled errors.
- Around line 30-31: The multipart parsing in body handling is collapsing
repeated field names because Object.fromEntries on event.req.formData() keeps
only the last value. Update the logic in the body utility to preserve duplicate
multipart entries instead of flattening them, and adjust the return shape
accordingly so repeated keys from formData are retained.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
|
Pushed e2e146c reworking this toward the opt-in design discussed above (#875). What changed
Open question: the thread said "if no options only json" — I kept the existing
|
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 `@docs/2.utils/1.request.md`:
- Line 28: The `readBody` documentation heading is malformed and the
`options.type` union is truncated, so fix the signature text in the
`readBody(event, options?: ...)` heading to use matching braces/parens and
include the full `type` union. Update the affected markdown heading so the
function signature is syntactically correct and reflects the complete allowed
`type` values.
In `@src/utils/internal/body.ts`:
- Around line 4-10: Both exported helpers in body.ts are missing explicit return
type annotations, which breaks declaration emit under isolatedDeclarations.
Update parseURLEncodedBody and parseFormData to declare their return types
directly, using the same type that collectEntries produces, so the exported
signatures are fully explicit and stable.
🪄 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: f61cafa7-57aa-499d-8eee-013b53c0923b
📒 Files selected for processing (4)
docs/2.utils/1.request.mdsrc/utils/body.tssrc/utils/internal/body.tstest/body.test.ts
| ``` | ||
|
|
||
| ### `readBody(event)` | ||
| ### `readBody(event, options?: { type?: "json")` |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Fix malformed function-signature heading.
Braces/parens are mismatched and the type union is truncated to "json" only.
📝 Proposed fix
-### `readBody(event, options?: { type?: "json")`
+### `readBody(event, options?: { type?: "json" | "text" | "urlencoded" | "formData" })`📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ### `readBody(event, options?: { type?: "json")` | |
| ### `readBody(event, options?: { type?: "json" | "text" | "urlencoded" | "formData" })` |
🤖 Prompt for 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.
In `@docs/2.utils/1.request.md` at line 28, The `readBody` documentation heading
is malformed and the `options.type` union is truncated, so fix the signature
text in the `readBody(event, options?: ...)` heading to use matching
braces/parens and include the full `type` union. Update the affected markdown
heading so the function signature is syntactically correct and reflects the
complete allowed `type` values.
Multipart form-data was previously parsed automatically based on the `Content-Type` header. Per h3js#875 this is now strictly opt-in via `readBody(event, { type: "formData" })` so an untrusted request can't drive readBody into (potentially expensive) multipart parsing. Also: - wrap `formData()` in try/catch -> HTTPError 400, matching the JSON path - preserve repeated form fields as arrays instead of dropping earlier values (shared with url-encoded parsing) - add readBody-based multipart tests (opt-in, no auto-parse, malformed 400) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…-type tests - `type: "text"` now returns an empty string for an empty body instead of `undefined`, matching the raw-string contract. - Extract a named `ReadBodyOptions` type (exported) so automd renders a clean `readBody(event, options?)` heading instead of mangling the inline string-literal union. - Add tests for the explicit `text`, `urlencoded`, and `json` modes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Summary by CodeRabbit
New Features
optionsparameter to request body parsing, includingtype: "formData"formultipart/form-data.ReadBodyOptionstype for the new API.Bug Fixes
400 Bad Requestfor invalid JSON.application/x-www-form-urlencoded(or when explicitly requested).undefined; repeated fields are preserved as arrays.Documentation
readBodydocumentation and examples to reflect the default JSON behavior and explicit multipart opt-in.Tests