【问题标题】:Unable to consistently load large json response using jquery.ajax无法使用 jquery.ajax 一致地加载大型 json 响应
【发布时间】:2012-03-17 12:57:30
【问题描述】:

最近,我的一个脚本开始面临从服务器加载 json 响应的问题。我正在使用 jquery.ajax() 进行 ajax 调用。代码sn-p就是这样-

var request = $.ajax({
  url: "script.jsp",
  type: "POST",
  dataType: "json",
  success: function(response) {
     console.log(response);
  }, 
  error: function(response, error) {
     console.log(response, error);
  }
});

正如我所提到的,这个脚本在昨天还有效。我没有对服务器端代码或前端代码进行任何更改。 json 响应有点大~1 MB。但我使用 -

验证了 json 输出
python -mjson.tool < output.json

打印正确。奇怪的是 FF 和 Chrome 处理它的方式不同。

在 FF 中,我打开 firebug 并看到正在发出的 ajax 请求。我看到请求在大约 300 毫秒内得到处理,但控制台中链接旁边的加载轮仍在动画大约 20 秒。之后,json 响应被正确处理,结果可以在页面上看到。在 IE 中也有类似的行为,在 20 秒后正确处理 json。

在 Chrome 中,大约 20 秒内没有任何反应,之后我在控制台中看到错误提示 "error": undefinedFailed to load resource。或者,它还打印以下堆栈跟踪 -

POST script.jsp 
f.support.ajax.f.ajaxTransport.sendjquery.min.js:4
f.extend.ajaxjquery.min.js:4
DataTableWidget.extend._fetchBuildingBlockItemsPermissionBBItemsWidget.js:91
(anonymous function)PermissionBBItemsWidget.js:83
e.extend.eachjquery.min.js:2
DataTableWidget.extend._loadDataPermissionBBItemsWidget.js:82
DataTableWidget.extend.showPermissionBBItemsWidget.js:15
(anonymous function)permission-building-blocks.html:451
xLAB.min.js:5
ULAB.min.js:5
jLAB.min.js:5
ILAB.min.js:5
eLAB.min.js:5
a.onload.a.onreadystatechange

我不明白在不同浏览器中这种奇怪的行为。

所以本质上我确保 -

  1. 服务器端代码快速返回响应。我输入了一些调试语句并查看了服务器日志。响应表单服务器的时间都不会超过 500 毫秒。
  2. 确保 json 得到正确验证。 20 秒后它在 IE 和 FF 中都被处理而没有任何问题的事实就是证明。除了使用python的json.tool。
  3. 将dataType设置为json

因此,有关该问题的任何指示都会有很大帮助。谢谢。

更新 我注意到另一件奇怪的事情。在处理请求时,我什至在原始请求的 3 秒内点击了刷新按钮,该过程立即完成。正如我在几分之一秒后看到视图的变化一样,页面由于刷新事件而被清除。

更新 2 我注意到,在我用字母分割我的大反应之后。长响应的问题只发生在某些响应中。我通过http://jsonformatter.curiousconcept.com/#jsonformatter 运行了这个拆分的长响应文件,虽然它立即返回说 josn 是有效的,但实际上打印响应需要 20 多秒。我认为问题是由于某些字符(如\u0026)而发生的,所以有了这个添加的信息,如何解决问题? Here is the snipet of the problematic json.

【问题讨论】:

  • 是时候考虑根据需求提供一些数据了??
  • @charlietfl 我确实考虑过,但我不明白为什么它昨天会起作用而不是今天。同样在另一页中,我提出了类似的要求,完全没有问题。

标签: javascript jquery ajax json post


【解决方案1】:

我发现了问题所在。问题在于服务器端代码如何为客户端代码 JavaScript 提供 json 字符串。

我在我们的代码库中使用了一个遗留方法,它实际上在将已经 json 字符串传递给客户端之前在 jsp 页面中呈现了该字符串。这以某种方式搞砸了响应。因此,响应类型也是 text/html。

一旦我将响应切换为实际的 application/json MIME 类型流,一切都很好。

【讨论】:

    【解决方案2】:

    您的 JSON 是否有换行符?你有 Firebug 或其他打开的线路吗?浏览器可能很好地加载了 JSON,它可能是你的调试工具出错了。我记得之前使用某些工具检查某些 JSON 字符串时遇到问题,只是因为它没有换行符(或 Windows 中理解的换行符)。我想知道您将整个内容记录到控制台这一事实是否与此无关。

    【讨论】:

    • 我再举一个例子。我不确定您选择的操作系统是什么,为了实验,我假设是 Windows。尝试在 Windows 记事本中打开一个长的、少换行的(可能是您的 JSON 文件)。加载可能需要 15/20 秒。现在,如果您尝试在 GVim 之类的工具中打开它,这是现代开源概念的编辑器,可能已经存在了 40 年,它应该会立即打开。不过,IIRC 在某些设置下也将像记事本一样工作。大多数编辑器不是为处理长的、无换行符的文件而设计的。
    • 而我谈论编辑器的唯一原因是大多数调试环境以类似方式(而且很差)处理相同的问题,如果这使我试图解释的内容更清楚的话。
    • 谢谢。但我发现他的问题。问题在于 hom 后端提供了带有 json 字符串的前端代码。我使用了一种遗留方法,它实际上在 jsp 页面中打印出已经 json 字符串,然后将其提供给前端。一旦我将响应切换为实际的 application/json MIME 类型流,一切都很好。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-10-16
    • 1970-01-01
    • 2020-01-23
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多