IE 8 dropping memory pages?

问题:

This question is a spin-off/evolution of this question. (That question got marked as resolved because I put a bounty on it and it auto-resolved, but it never really got answered.)

The summary is this: we have an ASP.NET site. Sometimes we get errors when the client asks for bizarre urls. From the resources the client is asking for, it looks like there is a 4k block of text missing from the html source.

A simple example...if we have a page that looks like this:

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

The client may ask for the url: "myValidLiORE%20STUFF%20LATER".

It acts as though a section of the html source just wasn't there...and that section that is missing seems to be exactly 4KB (4096 bytes) long (or according to some people, sometimes 1KB?).

Unfortunately, we are unable to replicate this error on demand, though we see it coming in from clients many times per day.

At first we thought this was a problem with Webresource.axd, because we happened to see it there a lot...but now I think that was primarily because we were grouping similar errors together, and those errors tended to happen when the corruption occured in that particular area. Now that I'm looking at a wider range of problems, I'm seeing places where we're getting very different errors that look like they're being caused by the same problem of dropping out a chunk.

We've seen this a lot with IE 8, and it has gotten more frequent as IE 8 has become more prevalent. We see it occassionally with a browser that reports itself as IE 7...which IE 8 will do if it's put into "compatibility mode".

My theory, at this point (which I'm trying to find a way to test) is that the web server is correctly sending out all of the data in the byte stream...and that the browser, IE 8, has a problem, and drops a memory page (4k) of it under some conditions.

I'm a bit worried about this theory, however, since apparently some people have reported seeing this "occassionally" with IE 6 or FF 3...these tend to be outliers, and could be just different problems with similar symptoms, but if it's really the same thing on those browsers, that would blow my theory out of the water. Still, I don't have a better idea at this point.

One other idea I've had is perhaps a relatively recent service pack to on the server is causing problems with the data being served to the clients, dropping the occasional 4KB. The problem with this theory is that it doesn't explain the great preponderance of the errors on IE 8, and the lack of them on other client browsers.

So the questions, which hopefully will eventually have answers:

1. Has anyone else encountered this? (maybe now that it's on your radar?)
2. Can anyone replicate this problem consistently?
3. Any ideas of what it is? Can you verify or refute my theory?
4. Are there any fixes or workarounds?

回答1:

**Edit 4/1/10: ** Update: The 4k bug is now fixed by the IE8 Cumulative update on 3/30/2010. blogs.msdn.com/ieinternals/archive/2010/04/01/

The Internet Explorer team has been investigating this issue.

-=Impact=-

Thus far, we believe the problem has no impact on the end-user's experience with the web application; the only negative effect is the spurious/malformed requests sent by the JavaScript speculative-download engine. When the script is actually needed by the parser, it will properly be downloaded and used at that time.

-=Circumstances=-

The spurious-request appears to occur only in certain timing situations, only when the pre-parser is forced to restart (as when a META HTTP-EQUIV tag containing a Content-Type with a CHARSET directive appears in the document) and only when a JavaScript SRC URL spans the 4096th byte of the HTTP response body.

-=Workaround=-

We currently believe this issue can generally be mitigated by declaring the CHARSET of the page using the HTTP Content-Type header rather than specifying it within the page.

So, rather than putting

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

In your head tag, instead, send the following HTTP response header:

Content-Type: text/html; charset=utf-8

Note that specification of the charset in the HTTP header results in improved performance in all browsers, because the browser's parsers need not restart parsing from the beginning upon encountering the character set declaration. Furthermore, using the HTTP header helps mitigate certain XSS attack vectors.

回答2:

http://blogs.msdn.com/ieinternals/archive/2009/07/27/Bugs-in-the-IE8-Lookahead-Downloader.aspx is the current post on this issue.

The Missing 4k Bug: The article states: "By declaring the CHARSET of the page using the HTTP Content-Type header rather than specifying it within the page, you can remove one cause of parser restarts." Eric Lawrence in an email: "Unfortunately, another known cause of parser restarts is use of XML namespaces, which your site appears to use." So if you use XHTML the 4K issue can occur!

回答3:

We have the same problem. I'm adding:

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

to our base page class. I'll report on the results shortly.

回答4:

FWIW Here are the stats I got from 1 month of logs in LogParser.

12331 hits to ScriptResource & WebResource / 183 errors

Broken down by useragent info. Seems to support the IE8 only theory (plus "compatibility mode" user agents).

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

The single non-IE8 error has no querystring at all, coming from a Firefox/3.5.3 browser (got to be unrelated).

I don't have any META HTTP-EQUIV="Content-Type" in my pages. Although I DO have this to bounce out non-Javascript users.

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