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
How I stumbled upon this: I have a barcode scan callback. It does some processing on barcode content, and then uses WebView Navigate to navigate the UI. params is a hash, which includes some decoded data as well as the original raw scan data.
In some cases, the raw data might contain some sequences that LOOK LIKE uri-encoded data. For example, this specific sequence: %96url_for() properly encodes this as %2596 and then after decoding yields the original %96.
The code above corrupts the query string by decoding what APPEARS to be uri-encoding but which is not. (For example, the + above will be turned into a space, and %96 will be turned into an invalid UTF-8 character and will be substituted with the substitution character.
While for my sample data the decoded data in controller correctly preserves the sequence %96 (encoded as %2596), it then corrupts the data by substituting (space) for any +.
@jtara, have you tried same scenarion on other platforms than Android ( iOS, win )? As a workaround, maybe encoding required data to base64 might help. Also, in latest release there is a possibility to use a native network stack instead CURL on Android, but you would need to use Tau extensions for that.
In
RhodesApp.cpp
,callback_redirect_to
I think should not decode the URL - or, at least should not decode any included query string.How I stumbled upon this: I have a barcode scan callback. It does some processing on barcode content, and then uses
WebView Navigate
to navigate the UI.params
is a hash, which includes some decoded data as well as the original raw scan data.In some cases, the raw data might contain some sequences that LOOK LIKE uri-encoded data. For example, this specific sequence:
%96
url_for()
properly encodes this as%2596
and then after decoding yields the original%96
.This gets internally redirected, like:
The code above corrupts the query string by decoding what APPEARS to be uri-encoding but which is not. (For example, the
+
above will be turned into a space, and%96
will be turned into an invalid UTF-8 character and will be substituted with the substitution character.I fixed locally by changing the last line:
But not sure if this is really a correct fix.
The code winds up here:
This seems perhaps vaguely relevant: curl/curl#473
The text was updated successfully, but these errors were encountered: