【问题标题】:Does the IE 10 browser have a shorter internal timeout than the Chrome browser?IE 10 浏览器的内部超时时间是否比 Chrome 浏览器短?
【发布时间】:2013-07-27 19:35:22
【问题描述】:

注意:我使用的是 IIS 7.5 服务器和 asp.net

我问的原因是因为我的 web 应用程序中的 httpRuntime 超时设置为 10 小时,目前。注意:可笑的高超时用于测试目的!这对 Chrome 非常有效,因为它的内部超时似乎比 IE 10 长得多。对于我的示例,我在开始流式处理之前在服务器上压缩大文件。这意味着浏览器必须等待一段时间才能开始从 Web 服务器接收数据。对于 1.2 GB 的文件,流式处理开始前大约需要 7 分钟。 Chrome 浏览器可以很好地处理这个问题。7 分钟后,文件开始下载。然而,在 IE 10 中,它只是进入了无限旋转模式。可能是一个小时后,流式传输仍然没有发生。这告诉我两个浏览器之间显然存在某种内部超时差异。是否有任何 http 响应代码可以发送到 IE 浏览器以强制它保持打开更长时间?非常感谢您的帮助!

【问题讨论】:

    标签: asp.net internet-explorer google-chrome httprequest httpresponse


    【解决方案1】:

    依赖这些等待时间是不明智的,因为它们会随着每个新版本而改变。

    为什么不让一个调用启动压缩并让浏览器在每 15 秒(或任何值)后轮询服务器以查看压缩是否完成。压缩完成后开始流式传输。这种模式很容易在 JavaScript 和 ASP.NET 中实现。

    【讨论】:

    • 实际上,您只是想到了我的长期解决方案。我计划使用 SignalR,它的作用类似于长轮询的工作方式,并且应该更有效地保持与 IIS 服务器的连接等。这更像是一个短期解决方案,让我暂时过关。
    • 另外,您推荐的轮询方法不适用于我的情况,因为我们在使用 Windows Azure 的云上。这意味着负载均衡器会改变多个 Web 服务器实例,因此无法预测哪个活动服务器正在进行压缩过程。对于 SignalR,有一种称为“背板”的东西可以处理这种情况。
    猜你喜欢
    • 2011-08-13
    • 2013-04-04
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-07-26
    • 2018-09-19
    • 1970-01-01
    • 2012-09-29
    相关资源
    最近更新 更多