-
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
bug: CapacitorHttp plugin does not fully support content-types other than JSON. #6299
Comments
I think it could be related to #6206 |
This issue needs more information before it can be addressed. In particular, the reporter needs to provide a minimal sample app that demonstrates the issue. If no sample app is provided within 15 days, the issue will be closed. |
It looks like this issue didn't get the information it needed, so I'll close it for now. If I made a mistake, sorry! I am just a bot. Have a great day! |
Thanks for the issue! This issue is being locked to prevent comments that are not relevant to the original issue. If this is still an issue with the latest version of Capacitor, please create a new issue and ensure the template is fully filled out. |
Bug Report
Capacitor Version
@capacitor/cli: 4.6.3
@capacitor/core: 4.6.3
@capacitor/android: 4.6.3
@capacitor/ios: 4.6.3
Platform(s)
Android
iOS
Current Behavior
As of commit #6165 the resulting change created an incosistnecy in how data from the CapacitorHttp module is sent between iOS and Android. Where iOS is sending data correctly as a form with the proper content type, the Android counterpart is just performing a .ToString() on the data object passed by the developer. This removes any support for posting forms, especially forms with multi-part/form-data on an Android platform. And can confirm this when comparing the Android variant with the iOS variant against a .NET Core Web API.
For context, compare the methods setting the request data in both cases. iOS's set data and Android's set data. Further more, referring to the former capacitor-community/http plugin, most of which I assume is just adapted code, used to work perfectly in a production environment and handled all of the necessary request content-types. Kindly refer to this code snippet as it's a tried and tested scenario.
Expected Behavior
The text was updated successfully, but these errors were encountered: