jQuery Cross-Domain Ajax JSONP Calls Failing Rando

Question

I am making cross-domain Ajax calls using the latest version of jQuery 1.7.1. with a JSONP response.

I have already tested it extensively on: Safari, Chrome, Opera, Firefox, IE6 IE7 IE8 IE9 (in compatibility mode and not) on Win XP and Win 7 all of them working flawlessly. Never failing on multiple tests. All of them using the standard default settings with JavaScript and Cookies enabled.

In production, the call very very rarely fails, but i've had several users out of hundreds that have. Probably one out of 50 or 100. I cannot make any sense of this because in all cases:

• The user did not have problems with non-cross-domain ajax calls using jQuery. (i.e. non-cross-domain calls worked so they must have JavaScript enabled and can support ajax).

• The user only had problems with cross-domain ajax calls using jQuery. Even after repeated attempts. I.e. the user would either have the problem or not, it would not fail then work or work then fail. Only one or the other.

• Here are a sample of the user agent strings of the users that where affected:

  Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; FunWebProducts)

  Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB7.2; .NET CLR 2.0.50727; .NET CLR 3.5.30729)

  Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; CPNTDF; ibrytetoolbar_playbryte; .NET4.0C)

It only seems to affect IE, i've never had the problem with other browsers.

• The problem goes away if they use a different browser, i told them to install Chrome.

• The problem cannot be connection, computer or OS based as changing browsers worked.

I can only rule out that it must be a setting that can only be found on IE. Has anyone had this issue? Does anyone have an idea of which IE setting might be blocking cross-domain Ajax calls with a JSONP response.

It cannot be the usual AJAX/JSONP/Cross-domain problems, since these problems do not occur when the browsers are set to default, and also because i've already done it the proper way: * timestamp string on the end to stop super caching * JSONP response etc etc

I can confirm that the call is not firing at all.

Answer 1

I have a feeling this is related to toolbars/extensions/spyware the users have installed. Of the 3 UAs provided, one has FunWebProducts, one has ibrytetoolbar_playbryte, and the other has the Google toolbar, which may be causing a problem, or it could be something else on their system that is perhaps intercepting requests. You could try to install various IE toolbars and see if the issue can be reproduced, but that may bring unwanted issues. Working around it may not be possible.

Answer 2

Use Fiddler2 to examine the http requests and responses and see what is being communicated back and forth.

Also, it may be an issue with TCP/IP v6 under the hood. We've experienced some problems with IE in the same context and the symptoms are almost always sporadic.

Answer 3

This issue has been plaguing me lately too. My research indicates that jQuery ajax calls are cached by IE so IE decides it doesn't need to get the data which would explain why nothing is happening. These SO questions helped Stop jquery load response from being cached and getjson returning cached data in IE8

It seems like the extra explicit ajax setting to disable caching helped IE get the message. All of the ajax calls in jQuery are supposed to avoid caching when json is the data type but I'm not convinced that it works. This is the code that seemed to help me, which you insert right before your getJSON() or ajax() call.

$.ajaxSetup({ cache: false });

Answer 4

This smacks of javascript timing issue. Because things execute in whatever order they feel like in javascript an issue somewhere else may be effecting your threat. IE you make your jsonp request but somewhere along the line something could blow up in your thread and cause an issue to the request. My guess is probably you are using innerHtml or innerText somewhere since those are sometimes not supported and sometimes they are.