Sending a FormData body and manually providing a content-type header

Should undici throw an error when sending a FormData body, either via request or fetch, when providing a content-type header?

The following will "work", but will cause the server to be unable to parse the formdata:

    const data = new FormData();
    data.append("url", url);
    data.append("capture_all", "on");

    const res = await fetch(`${process.env.WEB_ARCHIVE_BASE!}save/${url}`, {
        method: "POST",
        headers: {
            "Content-Type": "multipart/form-data",
        },
        body: data,
    })

note: this is an actual sample of code someone asked me to help them fix, as the endpoint was giving them a 400 status code (but working with curl)

should i be able to just throw a FormData instance at the undici fetch under the body key with a Content-Type: multipart/form-data header in node 21.2.0?
the result i get is not what i'd expect and my current guess is that the form data is wrong :firHmm:

the curl data to emulate would be

curl --request POST \
  --url https://web.archive.org/save/<snip> \
  --header 'Content-Type: multipart/form-data' \
  --form url=<snip> \
  --form capture_all=on

There are two different issues here:

• fetch doesn't implement forbidden headers, allowing a content-type to be provided.
• request will only append a content-type header if one does not exist.

The solutions are:

• throw an error, which is the easiest & would allow people to fix their code, rather than covering it up
• override the custom content-type header, which curl seems to do?

IMO when sending a FormData body there should never be an expectation of being able to send any other content-type, as without the undici-generated header, it literally can't be parsed by the server. I'd prefer throwing an error because there shouldn't be an expectation that these issues will get fixed by undici.

Start at the request and fetch entry points and trace how FormData bodies and an explicitly supplied Content-Type header are handled. Compare the two behaviors and determine the expected handling from the issue discussion; done means the chosen behavior is consistent and prevents an unusable multipart request.