You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The extraction of the value of the boundary of multipart/form-data requests fails for some requests 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). The current implementation only works with no surroundings of the boundary value and otherwise just includes them in the actual request body which will then fail on the server side where the serve will not be able to parse the request body.
In addition to that, the whole extraction currently just uses the last key of the Content-Type header which might not necessarily be the boundary but could also be something such as charset (see example implementation or MDN reference).
Other API Details
No response
Platforms Affected
iOS
Android
Web
Current Behavior
Let's consider the following request (assuming CapacitorHttp is active)
Because of CapacitorHttp is currently taking the last key of the Content-Type header as boundary the actual request body sent by CapacitorHttp will then look like:
--utf8
Content-Disposition: form-data; name="key"
value
--utf8--
The same request without the additional charset key but enclosed in double quotes: ( 'Content-Type': 'multipart/form-data; boundary="boundary"') will look like this:
--"boundary"
Content-Disposition: form-data; name="key"
value
--"boundary"--
The server will however read the boundary without quotes from the header and thus will be unable to parse the body.
Expected Behavior
For both cases the request body should look like this:
--boundary
Content-Disposition: form-data; name="key"
value
--boundary--
michaelwolz
changed the title
[Bug]: boundary is not extracted correctly from multipart/form-data requests when using CapacitorHttp
[Bug]: Boundary is not extracted correctly from multipart/form-data requests when using CapacitorHttp
Aug 14, 2024
Capacitor Version
The extraction of the value of the boundary of multipart/form-data requests fails for some requests 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). The current implementation only works with no surroundings of the boundary value and otherwise just includes them in the actual request body which will then fail on the server side where the serve will not be able to parse the request body.
In addition to that, the whole extraction currently just uses the last key of the Content-Type header which might not necessarily be the boundary but could also be something such as
charset
(see example implementation or MDN reference).Other API Details
No response
Platforms Affected
Current Behavior
Let's consider the following request (assuming CapacitorHttp is active)
Because of CapacitorHttp is currently taking the last key of the Content-Type header as boundary the actual request body sent by CapacitorHttp will then look like:
The same request without the additional
charset
key but enclosed in double quotes: ('Content-Type': 'multipart/form-data; boundary="boundary"'
) will look like this:The server will however read the boundary without quotes from the header and thus will be unable to parse the body.
Expected Behavior
For both cases the request body should look like this:
Project Reproduction
https://github.com/michaelwolz/multipart-form-data-not-working-on-ios
Additional Information
(Non-)working example can be found here: https://github.com/michaelwolz/multipart-form-data-not-working-on-ios/blob/master/src/js/capacitor-welcome.js#L76-L94
You install the current official version and it'll fail while working with the provided fix.
Pull-Request fixing the problem by accepting arbitrary position of the boundary and ignoring quotes: #7518
Fairly sure that the described behavior is also the origin of the following issues:
multipart/form-data
#7579The text was updated successfully, but these errors were encountered: