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

Add contentType to addParameter #659

Open
1 of 3 tasks
vallemar opened this issue Apr 9, 2024 · 3 comments
Open
1 of 3 tasks

Add contentType to addParameter #659

vallemar opened this issue Apr 9, 2024 · 3 comments

Comments

@vallemar
Copy link

vallemar commented Apr 9, 2024

Describe the solution you'd like
There are times when we want to declare the contentType of a parameter, as in this case: https://stackoverflow.com/a/60968768/6015400

Currently there is no way to declare the contentType of the parameter in question, it can only be done for the file

Are you willing to implement it and maintain it?

  • Yes
  • Can implement it with a Pull Request, but not maintain it
  • No
@gotev
Copy link
Owner

gotev commented Apr 10, 2024

Hi @vallemar from a protocol standpoint, key-values parameters passed in multipart form data are always strings. If the server requires the values to be something specific, it's weak to depend on the client. So, for the example you mentioned, on the server side it's possible to simply check if the string value is a json and return a 4xx validation error to the client if it's not. The server should do that validation in any case, whether you specify content type or not from the client.

@vallemar
Copy link
Author

Hi @gotev , yes, I understand the point, but always sending strings will be the default value, not always, frameworks such as axios, spring boot or the postman tool allow it so I understand that it will be an additional configuration within the protocol (I am not an expert). Thank you very much for your prompt response

@gotev
Copy link
Owner

gotev commented Apr 10, 2024

Sure, many tools allows it, but it's still an edge case and may cause problems with some servers, as it's not common standard. The library aims at providing the best compatibility with all kind of servers. For example, OkHttp doesn't allow this even in latest 5.x versions, as it follows strictly RFC 2387.

My 2 cents here if you're in an edge case like this: why a server would want to force the clients to do that? Specifying content types explicitly like that deviates from the standard, it increases payload size and does not add anything from a validation standpoint, as the server still gets form data params as raw url encoded input strings when reading from the stream.

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

No branches or pull requests

2 participants