Bug 143578 - Chrome: XMLHttpRequest executed in UIWebView encodes valid query string characters
Summary: Chrome: XMLHttpRequest executed in UIWebView encodes valid query string chara...
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: iPhone / iPad All
: P2 Normal
Assignee: Nobody
Keywords: InRadar
Depends on:
Reported: 2015-04-09 14:45 PDT by Eugene But
Modified: 2015-04-13 14:31 PDT (History)
3 users (show)

See Also:

Test App (25.64 KB, application/zip)
2015-04-13 14:04 PDT, Eugene But
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eugene But 2015-04-09 14:45:16 PDT
Steps to Reproduce:
Run this javascript:
var xhr = new XMLHttpRequest();
xhr.open('GET', '/?a[]=1');

Expected Results:
Page should send: GET: /?a[]=1

Actual Results:
Page sends: GET: /?a%5B%5D=1

Comment 1 Sam Weinig 2015-04-12 18:52:36 PDT
Does this only happen in the UIWebView/WKWebView, or does this also reproduce with Safari?
Comment 2 Eugene But 2015-04-13 07:17:59 PDT
Reproducible with mobile and desktop Safari.
Comment 3 Alexey Proskuryakov 2015-04-13 09:28:41 PDT
I cannot reproduce this with Safari 7.1.4 or 8.0.5. How did you test?

What I did was save the test to a local file, add <script> tags, prepend "" to the URL, and check the request with "nc -l 8000".
Comment 4 Eugene But 2015-04-13 09:46:54 PDT
I have the following HTHL page hosted on AppEngine:

    <button onclick="var xhr = new XMLHttpRequest(); xhr.open('GET', '/?a[]=new'); xhr.send();">
        Send XHR

After clicking the button I can see the following server side log:
[13/Apr/2015:09:35:09 -0700] "GET /?a%5B%5D=new HTTP/1.1" 302

This bug was originally submitted against Chrome for iOS: https://code.google.com/p/chromium/issues/detail?id=444848

I will ask the bug submitter (thomas@tjconcept.dk) to leave a comment for this issue.
Comment 5 Thomas Jensen 2015-04-13 12:54:42 PDT
I have only tested and reproduced this with success on Chrome for iOS, but I do have a list of user agents that showed the symptom in my server logs: https://code.google.com/p/chromium/issues/attachmentText?id=444848&aid=4448480002000&name=uas&token=ABZ6GAeK2igj_o4gx5sS9H4B6Q30vLvpvQ%3A1428954213832

As far as I remember, Safari did not have this issue, neither desktop or mobile.
Comment 6 Eugene But 2015-04-13 13:00:22 PDT
Chrome for iOS uses UIWebView. But I also thought that issue is reproducible with Safari 8.0.3 (10600.3.18), since server log for request was like this: "GET /?a%5B%5D=new HTTP/1.1". Sorry, maybe the symbols in logs were escaped.
Comment 7 Thomas Jensen 2015-04-13 13:18:13 PDT
> Sorry, maybe the symbols in logs were escaped.

They shouldn't be. The log exclusively "bad" requests and there are plenty of valid requests (by far the most) alongside these in the real log which are not escaped.
Comment 8 Alexey Proskuryakov 2015-04-13 13:19:34 PDT
In this case, it would be helpful if Chrome engineers could further isolate the issue. Chrome has an opportunity to modify the URL, as it implements its own networking, so it may be easier for Chrome engineers to check what happens there.
Comment 9 Eugene But 2015-04-13 13:30:00 PDT
I was not able to reproduce the issue with UIWebView using nc utility. The issue is reproducible with Chrome for iOS.

Closing the bug, thank you for quick response.
Comment 10 Eugene But 2015-04-13 14:04:28 PDT
Created attachment 250674 [details]
Test App
Comment 11 Eugene But 2015-04-13 14:08:47 PDT
The issue happens at NSURLProtocol level. URLRequest passed to canInitWithRequest: has encoded characters. You can use attached app to reproduce the issue:
1.) Build and run attached UIWebView test app
2.) Click/tap on "Send XHR" button
3.) Observe the log:

2015-04-13 14:04:55.151 UIWebView[7993:2115613] request: <NSURLRequest: 0x7f8bba401490> { URL: https://www.google.com/?a%5B%5D=1 }

Alexey, do you think it will be better to submit a separate WebKit bug for this issue?
Comment 12 Alexey Proskuryakov 2015-04-13 14:31:43 PDT
Seems fine to keep tracking it here.

This probably means that we take a parsed URL out of CoreFoundation at some point, instead of taking the original string.