jQuery跨域Ajax JSONP调用在某些IE版本中随机失败，原因不明
我正在使用最新版本的 jQuery 1.7.1 进行跨域 Ajax 调用。带有 JSONP 响应。
我已经对它进行了广泛的测试： Win XP 和 Win 7 上的 Safari、Chrome、Opera、Firefox、IE6 IE7 IE8 IE9（兼容模式和非兼容模式）都可以完美运行。在多次测试中从未失败。所有这些都使用启用了 JavaScript 和 Cookie 的标准默认设置。
在生产中，调用很少会失败，但我有数百个用户中有几个失败过。可能是 50 或 100 中的一个。我无法理解这一点，因为在所有情况下：
用户使用 jQuery 进行非跨域 ajax 调用时没有遇到问题。 （即非跨域调用有效，因此必须启用 JavaScript 并且可以支持 ajax）。
用户仅在使用 jQuery 进行跨域 ajax 调用时遇到问题。即使经过多次尝试。即用户要么有问题，要么没有问题，它不会失败然后工作或工作然后失败。只有其中之一。
以下是受影响用户的用户代理字符串示例：
Mozilla/5.0（兼容；MSIE 9.0；Windows NT 6.1；Trident/5.0；FunWebProducts）
Mozilla/4.0（兼容；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（兼容；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； MSIE
它似乎只影响 IE，我在其他浏览器上从未遇到过问题。
如果他们使用不同的浏览器，问题就会消失，我告诉他们安装 Chrome。
问题不可能是基于连接、计算机或操作系统的，因为更改浏览器有效。
我只能排除这一定是只能在IE上找到的设置。有人遇到过这个问题吗？有谁知道哪个 IE 设置可能会阻止使用 JSONP 响应的跨域 Ajax 调用。
它不可能是常见的 AJAX/JSONP/跨域问题，因为当浏览器设置为默认值时不会发生这些问题，而且因为我已经以正确的方式完成了它： * 时间戳字符串放在末尾以停止超级缓存 * JSONP响应 等等
我可以确认该呼叫根本没有触发。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这个问题最近也一直困扰着我。我的研究表明 jQuery ajax 调用由 IE 缓存，因此 IE 决定不需要获取数据，这可以解释为什么没有发生任何事情。这些SO问题帮助停止jquery加载响应被缓存和getjson 在 IE8 中返回缓存数据
这似乎是额外明确的禁用缓存的 ajax 设置帮助 IE 获取消息。当 json 是数据类型时，jQuery 中的所有 ajax 调用都应该避免缓存，但我不相信它有效。这是似乎对我有帮助的代码，您可以在 getJSON() 或 ajax() 调用之前插入该代码。
$.ajaxSetup({ 缓存: false });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 });使用 Fiddler2 检查 http 请求和响应并查看来回通信的内容。
此外，这可能是 TCP/IP v6 的潜在问题。我们在相同的环境中遇到过 IE 的一些问题，而且症状几乎总是零星的。
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.
这有点 javascript 计时问题。因为事情按照 JavaScript 中的任何顺序执行，其他地方的问题可能会影响您的威胁。即，您发出 jsonp 请求，但在该过程中的某个地方，某些东西可能会在您的线程中爆炸并导致请求出现问题。我的猜测是您可能在某处使用innerHtml 或innerText，因为这些有时不受支持，有时却受支持。
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.
我有一种感觉，这与用户安装的工具栏/扩展/间谍软件有关。在提供的 3 个 UA 中，一个具有 FunWebProducts，一个具有 ibrytetoolbar_playbryte，另一个具有 Google 工具栏，这可能会导致问题，或者可能是系统上的其他内容拦截了请求。您可以尝试安装各种 IE 工具栏并查看是否可以重现该问题，但这可能会带来不必要的问题。解决这个问题可能是不可能的。
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.