Bug 143578

Summary: Chrome: XMLHttpRequest executed in UIWebView encodes valid query string characters
Product: WebKit Reporter: Eugene But <eugenebut>
Component: WebKit2Assignee: Nobody <webkit-unassigned>
Status: REOPENED    
Severity: Normal CC: ap, sam, scss.dev1, thomas
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: iPhone / iPad   
OS: All   
Attachments:
Description Flags
Test App none

Eugene But
Reported 2015-04-09 14:45:16 PDT
Steps to Reproduce: Run this javascript: var xhr = new XMLHttpRequest(); xhr.open('GET', '/?a[]=1'); xhr.send(); Expected Results: Page should send: GET: /?a[]=1 Actual Results: Page sends: GET: /?a%5B%5D=1 rdar://20489255
Attachments
Test App (25.64 KB, application/zip)
2015-04-13 14:04 PDT, Eugene But 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Sam Weinig
Comment 1 2015-04-12 18:52:36 PDT
Does this only happen in the UIWebView/WKWebView, or does this also reproduce with Safari?
Eugene But
Comment 2 2015-04-13 07:17:59 PDT
Reproducible with mobile and desktop Safari.
Alexey Proskuryakov
Comment 3 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 "http://127.0.0.1:8000/" to the URL, and check the request with "nc -l 8000".
Eugene But
Comment 4 2015-04-13 09:46:54 PDT
I have the following HTHL page hosted on AppEngine: <html> <head></head> <body> <button onclick="var xhr = new XMLHttpRequest(); xhr.open('GET', '/?a[]=new'); xhr.send();"> Send XHR </button> </body> </html> 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.
Thomas Jensen
Comment 5 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.
Eugene But
Comment 6 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.
Thomas Jensen
Comment 7 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.
Alexey Proskuryakov
Comment 8 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.
Eugene But
Comment 9 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.
Eugene But
Comment 10 2015-04-13 14:04:28 PDT
Created attachment 250674 [details] Test App
Eugene But
Comment 11 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?
Alexey Proskuryakov
Comment 12 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.
Note You need to log in before you can comment on or make changes to this bug.