Sending a FormData body and manually providing a content-type header about undici HOT 4 OPEN

Especially as it feels pretty unique to multipart/form-data (at least for now).

It is unique to multipart/form-data, as without the boundary type provided in the content-type header, it can't be parsed.
https://datatracker.ietf.org/doc/html/rfc7578

"boundary" is now a required parameter in
Content-Type.

I would keep supporting it in request() and override it in fetch().

Here's where we'd implement the logic. I wonder if we should take a look at reimplementing a subset of forbidden headers as we've had nothing but issues (host header) and security vulnerabilities (cookie, authorization, proxy-authorization) by not implementing them. Originally I wanted to follow Deno's behavior, but I'm second guessing my judgement... I know ronag's disapproved removing them too, way back when.

https://github.com/nodejs/undici/blob/ae9587193403bccac4fdfe9ebc882c5240538cf3/lib/fetch/request.js#L507-509

from undici.

Agree with the statement that these scenarios should be handled by the users rather than undici or fetch doing its best guest to cover that up.

However, I'm a little over the fence if this is something that should be changed within undici or maybe a documentation improvement to be done. Especially as it feels pretty unique to multipart/form-data (at least for now).

Should we consider adding a documentation improvement and a possible warning before considering it to throw?
As said earlier, the only thing that it worries me is that this is becomes pretty specific to multipart/form-data only

from undici.

I would keep supporting it in request() and override it in fetch().

from undici.

IMHO those are needed for compat with the rest of the Node.js ecosystem.

SGTM on the implementation of in request.

from undici.