Skip to content
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

Support for application/x-www-form-urlencoded Content-Type as body type formdata currently only supports multipart/form-data #337

Open
AcousticDeveloper opened this issue Mar 20, 2024 · 3 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@AcousticDeveloper
Copy link
Contributor

AcousticDeveloper commented Mar 20, 2024

Describe the bug/problem
Currently whenever the formdata is selected as request body, the Content-Type header is set to multipart/form-data but this should be dependent upon whether there is a file being uploaded too or else it can be set to the default application/x-www-form-urlencoded.

Relevant References
stackoverflow: application/x-www-form-urlencoded or multipart/form-data?
baeldung: Difference Between form-data, x-www-form-urlencoded and raw in Postman

Steps to Reproduce the bug/problem
Select POST request in the request method, select formdata as the request body, add only text fields as fields, and then we can either chck the codegen for languages where Content-Type is printed, or else we can print requestModel.requestBodyContentType.header inside codegen files to check the request header.

image

Expected behavior
If there aren't any files uploaded i.e. all the fields are of text type and selected type is formdata, then the Content-Type should be set to application/x-www-form-urlencoded, and if there is at least one file in the form data, then the Content-Type should be multipart/form-data. As the default Content-Type for HTML form submission is application/x-www-form-urlencoded, hence it is worth introducing in API dash.

Reference: Mozilla Documentation
image

Fixing this should start from introducing a new sub-type inside consts.dart file and then creating a new ContentType for the new type and setting up the Content Type based on whether there are any files associated with the request or not. Below are some code snippets from consts.dart which are to be modified to start working on this issue.

image
image

Device Info (The device where you encountered this issue):

  • OS: Debian 12 WSL2 on Windows 11
@AcousticDeveloper AcousticDeveloper added the bug Something isn't working label Mar 20, 2024
@AcousticDeveloper AcousticDeveloper changed the title Support for application/x-www-url-encoded Content-Type as body type formdata currently only supports multipart/form-data Support for application/x-www-form-urlencoded Content-Type as body type formdata currently only supports multipart/form-data Mar 20, 2024
@animator animator added enhancement New feature or request good first issue Good for newcomers and removed bug Something isn't working labels Mar 20, 2024
@ashitaprasad
Copy link
Member

ashitaprasad commented Apr 15, 2024

A new content-type needs to be added but in UI it can be done in two ways:

  • Adding x-www-form-urlencoded in content type dropdown. Users will be able to add text fields and select only files containing text data and tells user to switch to multipart/form-data whenever a file with binary content (image, video, etc) is selected.
  • Adding a toggle switch somewhere in existing form-data which defaults to x-www-form-urlencoded and can be toggled to multipart. It will be more intuitive and require less changes in the model. Users will be able to explicitly switch to multipart. It can also automatically switch to multipart whenever a file with binary content (image, video, etc) is selected by the user.

@himanshugoyal77
Copy link

@ashitaprasad I would like to give it a try

@ashitaprasad
Copy link
Member

Sure @himanshugoyal77 you can give it a try. It will be assigned once you send across a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

4 participants