-
Notifications
You must be signed in to change notification settings - Fork 511
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sending a FormData body and manually providing a content-type header #2736
Comments
Agree with the statement that these scenarios should be handled by the users rather than However, I'm a little over the fence if this is something that should be changed within Should we consider adding a documentation improvement and a possible warning before considering it to |
I would keep supporting it in |
It is unique to multipart/form-data, as without the boundary type provided in the content-type header, it can't be parsed.
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 ( |
IMHO those are needed for compat with the rest of the Node.js ecosystem. SGTM on the implementation of in request. |
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:
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)
There are two different issues here:
The solutions are:
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.
The text was updated successfully, but these errors were encountered: