IE 8丢弃内存页面?

时间:2009-05-07 14:52:05

标签: internet-explorer memory

这个问题是this question的衍生/演变。 (这个问题被标记为已解决,因为我对它提出了一个赏金并自动解决了,但它从未得到过真正的回答。)

摘要是这样的:我们有一个ASP.NET站点。有时候,当客户要求奇怪的网址时,我们会收到错误。从客户端要求的资源来看,html源代码中缺少4k块文本。

一个简单的例子......如果我们有一个看起来像这样的页面:

<a href="myValidLink.aspx">Here's some text</a>
a bunch more stuff
...(a large block of text)...
AND NOW MORE STUFF LATER

客户可能会要求提供网址:“myValidLiORE%20STUFF%20LATER”。

就好像html源的一部分不在那里......并且那个缺失的部分似乎正好是4KB(4096字节)长(或根据某些人,有时是1KB?)。 / p>

不幸的是,我们无法按需复制此错误,但我们每天都会看到它多次来自客户。

起初我们认为这是Webresource.axd的一个问题,因为我们碰巧在那里看到了很多......但现在我认为这主要是因为我们将类似的错误分组在一起,而这些错误往往发生在那个特定地区发生了腐败现象。现在我正在研究更广泛的问题,我看到的地方我们得到了非常不同的错误,看起来它们是由同样的辍学问题造成的。

我们已经在IE 8中看到了很多,并且随着IE 8变得越来越流行,它变得越来越频繁。我们偶尔会看到它自称为IE 7的浏览器......如果IE 8进入“兼容模式”,IE 8将会这样做。

我的理论,此时(我试图找到一种测试方法)是Web服务器正确发送字节流中的所有数据......以及浏览器IE 8,有一个问题,并在某些条件下删除它的内存页面(4k)。

然而,我对这个理论有点担心,因为显然有些人报告说IE 6或FF 3“偶尔”看到这些......这些往往是异常值,可能只是出现类似症状的不同问题,但如果在这些浏览器上真的是同样的东西,这会让我的理论脱离水面。不过,我现在还没有更好的主意。

我所拥有的另一个想法可能是服务器上相对较新的服务包导致向客户端提供的数据出现问题,偶尔会丢失4KB。这个理论的问题在于它没有解释IE8上错误的优势,以及其他客户端浏览器上的错误。

所以这些问题最终会得到答案:

  1. 还有其他人遇到过这个吗? (也许现在它在你的雷达上?)
  2. 任何人都能一致地复制这个问题吗?
  3. 有什么想法是什么?你能证实或反驳我的理论吗?
  4. 是否有任何修复或解决方法?

4 个答案:

答案 0 :(得分:12)

**编辑4/1/10:** 更新:4k错误现在由2010年3月30日的IE8累积更新修复。 blogs.msdn.com/ieinternals/archive/2010/04/01 /

Internet Explorer小组一直在调查此问题。

- =影响= -

到目前为止,我们认为该问题对最终用户使用Web应用程序的体验没有影响;唯一的负面影响是JavaScript推测下载引擎发送的虚假/格式错误的请求。当解析器实际需要脚本时,它将在那时正确下载和使用。

- = =境遇 -

虚假请求似乎仅在某些定时情况下发生,只有当预解析器被强制重启时(如文档中出现包含具有CHARSET指令的Content-Type的META HTTP-EQUIV标记)并且仅当JavaScript SRC URL跨越HTTP响应正文的第4096个字节时。

- = =解决方法 -

我们目前认为,通常可以通过使用HTTP Content-Type标头声明页面的CHARSET而不是在页面中指定它来缓解此问题。

所以,而不是把

[META HTTP-EQUIV =“Content-Type”CONTENT =“text / html; charset = utf-8”]

在head标签中,发送以下HTTP响应标头:

Content-Type:text / html;字符集= UTF-8

请注意,HTTP标头中的charset规范可以提高所有浏览器的性能,因为浏览器的解析器在遇到字符集声明时无需从头开始重新解析。此外,使用HTTP标头有助于缓解某些XSS攻击媒介。

答案 1 :(得分:2)

http://blogs.msdn.com/ieinternals/archive/2009/07/27/Bugs-in-the-IE8-Lookahead-Downloader.aspx是关于此问题的当前帖子。

失踪的4k Bug: 该文章指出:“通过使用HTTP Content-Type标头声明页面的CHARSET而不是在页面中指定它,您可以删除解析器重新启动的一个原因。” Eric Lawrence在一封电子邮件中: “不幸的是,解析器重新启动的另一个已知原因是使用XML命名空间,您的站点似乎使用它。”因此,如果您使用XHTML,可能会发生4K问题!

答案 2 :(得分:0)

我们遇到同样的问题。我正在补充:

        Response.ContentType = "text/html"
        Response.Charset = "utf-8"

到我们的基页类。我很快就会报告结果。

答案 3 :(得分:0)

FWIW以下是LogParser中1个月日志的统计数据。

12331 hits to ScriptResource & WebResource / 183 errors

按使用者信息细分。似乎只支持IE8理论(加上“兼容模式”用户代理)。

cs-uri-stem           MSIEVersion TridentVersion  COUNT
/WebResource.axd      MSIE+8.0    Trident/4.0     100
/ScriptResource.axd   MSIE+8.0    Trident/4.0     36
/WebResource.axd      MSIE+7.0    Trident/4.0     44
/ScriptResource.axd   MSIE+7.0    Trident/4.0     2
/ScriptResource.axd   NOT IE      NOT Trident     1

单个非IE8错误根本没有查询字符串,来自Firefox / 3.5.3浏览器(必须与之无关)。

我的网页中没有任何META HTTP-EQUIV =“Content-Type”。虽然我有这个来反弹非Javascript用户。

<noscript>
    <meta http-equiv=Refresh content="0; URL=/ErrorPage.aspx?Error=NoJavascript">
</noscript>