Fix boundary value extraction for form-data requests

[michaelwolz]

The changes introduced in #7306 fixed several bugs with multipart/form-data requests on iOS. However, the extraction of the actual boundary value might fail due to the value being surrounded by double quotes, which is allowed and happens occasionally (See MDN Reference which utilizes double quotes for the boundary in their example: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/POST#example).

In addition, the Content-Type header might include other keys such as charset.

This change extracts the boundary value regardless of the order of the individual keys within the Content-Type header.

Example Code

(Assuming that the plugin override is enable in capacitor.config.ts)

const body = new FormData();
body.append('key', 'value');

await fetch(url, { method: 'POST', body, 
  headers: {
    'Content-Type': 'multipart/form-data; boundary="boundary"; charset=utf8'
    //  'Content-Type': 'multipart/form-data; boundary="boundary"'
  }
});

The current implementation only considers the last string after any equal sign (contentType.components(separatedBy: "=").last). This results in --utf8 being set as the boundary in the request body. Even if there is no other key involved in the request it will include double quotes " in the request body, leading to a malformed request.

Working example including the changes can be found here:
https://github.com/michaelwolz/multipart-form-data-not-working-on-ios

[michaelwolz]

Actually I just saw that the same issue exists with Android. I will try to also provide a fix for this :).

Edit: Done in bc6a6e0, example app also updated to include android platform

[michaelwolz]

Note that this part was missing in the iOS implementation but present for Android already.

[barillax]

thanks @michaelwolz ! This fix worked to unblock us. Looking forward to it getting upstream 🤞

[heath-pack]

@michaelwolz We used these changes to help unblock us as well, thanks!

We also needed to add a change to the convertFormData function of the native-bridge code.
It has a check on if (value instanceof File) { to correctly encode a file and add it as formData.

We ended up changing it to something like if (value instanceof File || value instanceof Blob) { so that blobs are also correctly encoded and added to the formData.

I think it would be great if that change could be included with your PR as well so that we really do end up having full support for form-data requests after this gets merged! WDYT?

[michaelwolz]

@heath-pack In my opinion this is a different issue. I would like to get some official feedback on the PR by the capacitor team first. But you can create an issue (and PR) for this on your own.

[abhishekiqz]

Hello Team is there any update on this PR, @michaelwolz please update this pr to base branch and make a new pr

[czimnick]

The if condition on line 197 is never reached maybe only on xhr requests or on both.
In native-bridge.js, it seems the Content-Type header is not being set. Could this be related to the issue?

Additionally, I am encountering a problem where my POST requests with (angular httpClient) multipart/form-data result in an empty body. This might be relevant to the bug described here: #7579.

android
https://github.com/ionic-team/capacitor/blob/main/android/capacitor/src/main/assets/native-bridge.js#L129
Called here (fetch proxy possible working) -> https://github.com/ionic-team/capacitor/blob/main/android/capacitor/src/main/assets/native-bridge.js#L493
Called here (xhr proxy bugged) -> https://github.com/ionic-team/capacitor/blob/main/android/capacitor/src/main/assets/native-bridge.js#L623

ios
https://github.com/ionic-team/capacitor/blob/main/ios/Capacitor/Capacitor/assets/native-bridge.js#L129
called here (fetch proxy maybe bugged) -> https://github.com/ionic-team/capacitor/blob/main/ios/Capacitor/Capacitor/assets/native-bridge.js#L493
called here (xhr proxy bugged) -> https://github.com/ionic-team/capacitor/blob/main/ios/Capacitor/Capacitor/assets/native-bridge.js#L623

[michaelwolz]

This code is definitely reached for regular fetch requests. Please feel free to checkout the provided example in the PR description which shows a minimal example using a fetch request. I also just updated the example to the latest capacitor version.

I am not sure that your issue is really related to the bug I tried to address here. This PR is only about wrong handling of form data boundaries.

[czimnick]

Okay, never mind—I found the issue. Sorry for the interruption.

If you don’t set the Content-Type header explicitly, the CapacitorHttp proxy will not automatically add a default Content-Type header and ignore the body.
In web the browser will handle this and add a default Content-Type...

I tested this behavior using your example app.