Comments on: Changing the headers for UIWebKit HTTP requests

By: Alexander

Alexander — Wed, 20 Mar 2013 13:35:12 +0000

@Alex
You have to avoid showing the Alert within(!) the AJAX context. As long as the alert box is shown (an alert box is a modal window), the Javascript execution stops until the user has dismissed it. And therefore the AJAX execution also stops. Which means the notification about the end of the AJAX context also has to wait.

So maybe if you need to shot an alert box t the user, open it after the AJAX call has ended, maybe open the alert box via timer, so it is not directly linked to the AJAX context anymore.

By: Alex

Alex — Wed, 20 Mar 2013 07:05:16 +0000

@Alexander:

Yes! you’re right! The problem is caused by sync ajax.(JQuery v1.9, but not happened in v1.4), and stopLoading is not called before I close the “popup win” in the web page.

But is there any way to notify the iOS to call “stopLoading” after data received?
Thanks!

By: Alexander

Alexander — Mon, 18 Feb 2013 14:51:00 +0000

@Alex
In general this should work just fine. I’ve checked this myself again, and all the methods (including stopLoading) are called as expected. Is there a special reason why you’re using a synchronous Ajax call? Normally you should avoid synchronous Ajax requests whenever possible.

But in case your still using iOS 6.0.0, you should definitely update, because iOS 6.0.0 has some serious bugs which caused that an App should not always find out if the page loading has finished (even the “isLoading” method of UIWebView did return “YES” when the page load was definitely finished).

Also please note that when showing a Javascript “alert” (for example for debugging) within the context of the XMLHttpRequest, the request is stopped until the alert is dismissed. And this also means that “stopLoading” is not called until the alert box is dismissed.

By: Alex

Alex — Mon, 18 Feb 2013 01:49:30 +0000

Hi, @Alexander, I found a problem, I use NSURLProtocol to filter the request from UIWebView, but I found a webpage contains this JS code:

 $.ajax({
        async: false, cache: false, type: "get", dataType: "text",
        url: "/Order/OrderTrackLine/" + formcode + "?province=" + escape(province) + "&status=" + status,
        data: "",
        beforeSend: function () { $("#info" + formcode).html("正在读取，请稍候..."); },
        success: function (data) {

            $("#info" + formcode).html(data);
        },
        error: function (XMLHttpRequest) { },
        complete: function (XMLHttpRequest) { }
    });

NSURLProtocol can capture this request, but after -connectionDidFinishLoading: called, nothing continue, that's say, -stopLoading method isn't called, and the content that fetched by this ajax request can't be shown in the web page. I don't know why.

By: Alexander

Alexander — Fri, 29 Jun 2012 21:59:49 +0000

@Alex
OK, maybe you should use a network sniffer to check what exactly is going on here. Please note that there can be also HTTP redirections, which you also need to process in the NSURLProtocol. If you don’t, the UserAgent header might be missing for redirections and if the server doesn’t like this, you might see some unexpected results.

By: Alex

Alex — Fri, 29 Jun 2012 02:48:17 +0000

@Alexander: sorry I didn’t explain clearly, the “window” is not a real window, just a region that covers the part of the original page, and it looks like a “window”, this region may rendered by CSS or some else.

when user click the link, it won’t open a new page, just show this “window”.

By: Alexander

Alexander — Thu, 28 Jun 2012 12:10:34 +0000

@Alex
I’m not sure if the AJAX issue is really related to NSURLProtocol. There’s a general unsolvable problem with popup windows in the iOS: The UIWebView API does not support multiple windows, so it does not have any method that deals with popup windows. And this means that all attempts of a web page in opening a new window will be silently ignored by UIWebView. No window will ever open.

So in order to get popup windows or links open in new windows or tabs, you as a developer need to modify the web page, modify link targets, overwrite the “window.open” property of JavaScript to get notified when a web page tries to open a new window, and then open the window yourself outside of the context of the UIWebView. This works find in most cases, but it fails if a web page is using the reference to the new window that is normally returned by the “window.open” call. This is because even if you’ve opened a new
window and created a new instance of UIWebView for this “window-open” call, you can not pass back the reference to the new window as return value of this “window.open” call. So whenever a web page tries to use a window references that was returned by window.open, it will fail, because this can never be a valid reference to the new window.

And web pages might use this reference to pass new content to the new window. And this will fail.

By: Alex

Alex — Thu, 28 Jun 2012 08:49:00 +0000

—————————————–
As I noted above in one comment, I assume the only “legal” way to change the UserAgent that also works under iOS 5 is to implement your own HTTP protocol handler using NSURLProtocol, which is a public API.
—————————————–
@Alexander: I did use NSURLProtocol to hook the request of UIWebView, but I found a problem: some webpages, when user clicks a link, will popup a “window”, and the content of the “window” is fetched by ajax. if i use NSURLProtocol to hook the request, the “window” won’t popup, I don’t know why.

sorry for my poor English -_-!!!

By: Alexander

Alexander — Wed, 06 Jun 2012 12:43:28 +0000

@mk
You are right, this approach does no longer work under iOS 5. UIWebView still uses NSMutableURLRequest objects, but it does no longer use the public API to set or change its properties.

The only solution left to change the HTTP headers is much more complicated, because you have to write your own HTTP protocol handler using the NSURLProtocol class.

By: mk

mk — Wed, 06 Jun 2012 05:00:39 +0000

hi
thanks for the great post!
i am trying to use your approach in ios 5.
the swizzleMethod is called at runtime, but
- (void)newSetValue:(NSString *)value forHTTPHeaderField:(NSString *)field
never gets called at runtime.
do you know if the uiwebview implementation in ios5 still uses NsMutableUrlRequest ?

Cheers from Austria
Martin

By: Daniel

Daniel — Fri, 13 Jan 2012 23:38:06 +0000

For my prototype app I don’t care if I have to use a private API, so the solution from henry yan would be perfect. But in my App I’m using ARC and I think mainly this cast “(void**)&webView)” gives an error when trying to compile and using ARC. Does someone know how to change the code from henry to make it compile when using ARC? (I know, I really should study the ARC internals more profoundly…)

By: Alexander

Alexander — Thu, 15 Dec 2011 11:20:59 +0000

@henry yan
What you’re proposing would use private API. This might be fine for App that are only used by you or in your company or when developing for the “jailbreak” market, but it is definitely not allowed in the AppStore. Apple might reject your App right away if you use the private API, or they might pull it later from the AppStore, when they find out what you’re doing.

As I noted above in one comment, I assume the only “legal” way to change the UserAgent that also works under iOS 5 is to implement your own HTTP protocol handler using NSURLProtocol, which is a public API.

By: henry yan

henry yan — Thu, 15 Dec 2011 09:09:23 +0000

it seems we have to do this workaround to change User-Agent, not sure Apple allow to do this.
I just do the test on iPhone Simulator (iOS 5), and it works well so far.
————–8<——————————————–
NSString *userAgent = @"Mozilla/5.0 (iPad; U; CPU OS 4_3_3 like Mac OS X; ja-jp) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8J2 Safari/6533.18.5";

id webDocumentView;
id webView;
webDocumentView = objc_msgSend(mWebView, @selector(_documentView));
object_getInstanceVariable(webDocumentView, "_webView", (void**)&webView);
objc_msgSend(webView, @selector(setCustomUserAgent:), userAgent);
————–8<——————————————–

By: Alexander

Alexander — Mon, 17 Oct 2011 16:35:05 +0000

@groumpf
You could do this, but I guess this will not work very well in general. The resources are not covered this way, but these can be important as well. And when you load the main requests yourself and then feed the result to UIWebView as NSData or as string, you lose all the background loading ability or UIWebView. So everything will be much slower.

By: groumpf

groumpf — Mon, 17 Oct 2011 13:41:03 +0000

@Alexander thank for reply
I’m wondering if another (slightly easier ?) solution could be to execute each request instead of letting the UIWebView doing it. You can then make the request you like, get the result in a string and pass it to the UIWebView loadHTMLString and do the same on shouldLoad…
Except for the resources, it should work.