fix: reject cross-realm FormData request bodies

[Pyker]

This relates to...

Fixes #5520. Related context: #5500 / #5502 (legacy dispatcher bridge), #5016 and #4285 (fetch-side cross-realm FormData behavior, unchanged here).

Rationale

request() accepts FormData bodies through the duck-typed util.isFormDataLike() check, but only undici's own FormData can be encoded: the multipart extraction is gated on the webidl.is.FormData brand check. A FormData from another realm (Node.js' builtin globalThis.FormData, another undici copy, a polyfill) passed the gate, fell through the extraction, and was dispatched as a body that never produced any bytes: the request hung silently until an external timeout, with zero bytes written to the socket (full version matrix and reproductions in #5520).

Per review direction (encode vs reject, maintainers chose reject): such bodies now fail fast with InvalidArgumentError. The check lives in the Request constructor, where other invalid body types are already rejected, so both the HTTP/1 and HTTP/2 clients reject cleanly at dispatch time and the fetch code is untouched. The FormData brand check is loaded lazily so the fetch machinery is not pulled in upfront.

Note for changelog purposes: this is a behavior change relative to v6, which encoded cross-realm FormData successfully (v7.0.0 through 7.19.x failed these bodies with an unrelated TypeError; 7.20.0+ hung).

Changes

• lib/core/request.js: FormData-like bodies that are not instances of undici's FormData now throw InvalidArgumentError instead of falling through to iterable handling.
• test/issue-5520.js: cross-realm FormData rejection over HTTP/1 and HTTP/2 (own-FormData encoding is already covered by test/client-request.js and test/http2-body.js).

Features

N/A

Bug Fixes

• request() with a FormData from another realm now rejects immediately with a clear error instead of hanging forever.

Breaking Changes and Deprecations

N/A (the affected input previously hung or produced a broken body; it never worked on v7/v8)

Status

• I have read and agreed to the Developer's Certificate of Origin
• Tested (test/issue-5520.js plus unit, fetch, client-request, http2-body and h2 core suites; lint clean)
• Benchmarked (optional)
• Documented (behavior fix; error message self-describes)
• Review ready
• In review
• Merge ready

[KhafraDev]

This shouldn't be under web/fetch, if this is something we want to support at all.

[Pyker]

Moved it out of web/fetch in 5faa679: body.js is now untouched and the rebuild lives in lib/dispatcher/formdata-body.js, next to its only consumers.

On supporting it at all: the h1/h2 clients already accept any FormData-like through util.isFormDataLike(), and today that acceptance ends in a silent hang with zero bytes on the wire. So the real choice is encode it (this PR, matches v6) or tighten the gate to the brand check and throw InvalidArgumentError (loud, but breaks request() + Node's global FormData, which worked on v6). I prefer the first; happy to rework to the second if that is the direction you want.

[mcollina]

lgtm

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.44%. Comparing base (0dee09d) to head (5faa679).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5521      +/-   ##
==========================================
- Coverage   93.44%   93.44%   -0.01%     
==========================================
  Files         110      111       +1     
  Lines       37329    37367      +38     
==========================================
+ Hits        34883    34918      +35     
- Misses       2446     2449       +3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[KhafraDev]

Is this something we want to support? We don't support this pattern anywhere else. Wouldn't it make more sense to just throw an error?

[mcollina]

Is this something we want to support? We don't support this pattern anywhere else. Wouldn't it make more sense to just throw an error?

Actually yes, it would be.

[Pyker]

Reworked to reject, per the discussion: the Request constructor now throws InvalidArgumentError for FormData-like bodies that are not undici's own FormData, alongside the existing invalid-body rejections, so h1 and h2 both fail fast at dispatch time. The encode helper is gone and web/fetch is untouched (the brand check is lazy-loaded). One note for future bisecters: v6 encoded these successfully, so this formalizes the stricter v7+ behavior with a clear error instead of the hang.