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

Content-Type header with application/json should be assumed if there is a request body #1525

Closed
RobbyUitbeijerse opened this issue Jul 19, 2024 · 2 comments · Fixed by #1529
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@RobbyUitbeijerse
Copy link
Contributor

Hello!

It feels very logical to us for a default Content-Type': 'application/json' header to be assumed if there are any requestBodyParams. Reasoning being that currently, in the fetch template, the body is provided through JSON.stringify(), but not all services accept the payload if you don't pass the header. I do realize these can simply be passed through options (either per request/global), but the default seems sensible.

Let me know how you feel about it, happy to provide a PR.

@RobbyUitbeijerse RobbyUitbeijerse changed the title Content-Type header with application/json should be assumed if the default is to stringify the boyd Content-Type header with application/json should be assumed if there is a request body Jul 19, 2024
@melloware
Copy link
Collaborator

This seems reasonable to me. Please submit a PR

@melloware melloware added the enhancement New feature or request label Jul 19, 2024
@soartec-lab
Copy link
Collaborator

@RobbyUitbeijerse

The fetch client doesn't yet support cases other than application/json, such as multipart/form-data and application/x-www-form-urlencoded so i'll do this by following response.

#1387 (comment)

I plan to add a header to the fetch client options when content-type is specifyed in OpenAPI so, i 'll fix this issue as well 👍

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

Successfully merging a pull request may close this issue.

3 participants