-
Notifications
You must be signed in to change notification settings - Fork 1k
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
fix(android): get application/x-www-form-urlencoded as string #6165
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Tested this with one of the supplied reproductions and it worked.
As far as I know, I don't think you have to worry about JSObjects from a x-www-form-urlencoded
response. if that does happen, it should be on the caller to take the body response and parse as JSON.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
x-www-form-urlencoded
requests should always be sent with URL Query String formatted bodies. Users can accomplish this via a couple options:
-
URLSearchParams in JS
-
A custom mapping function that will convert your JS Object into query params:
const bodyRequest = Object.keys(myJSObject).map(key => `${encodeURIComponent(key)}=${encodeURIComponent(myJSObject[key])}`).join('&');
In this case the Cap HTTP Plugin was accepting users sending JSON strings then auto converting them for users.
Hello, when can we expect to have this fix with the next release of capacitor? Thanks! |
This was released in 4.6.2 |
Hi, any reason why this was introduced? I'm using this in conjunction with an .NET Core Web API and can confirm that the above is resulting in malformed requests. Comparing this to the old capacitor-community http plugin, this amendment leaves a lot unhandled especially when it comes to multi-part/form-data. Applying .ToString() on any http request params other than application/json will not render anything useful. Other forms of encoding are a must for this to work in a more complex scenario. Kindly refer to this snippet here. Thanks in advance. |
As far as I understand, when using
application/x-www-form-urlencoded
you send a string, so that's why thebody.toJSObject()
is crashing, because it's a string, not a JSObject.The PR removes the whole
application/x-www-form-urlencoded
else and goes directly to the final else where it read the body as string.If you think there might be bases where the
application/x-www-form-urlencoded
could be getting aJSObject
, let me know and I'll change the code to catch the JSON exception and fallback to string in that case.closes #5996