IE 8 dropping memory pages?

Question

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?

Answer 1

Yes, we've seen this too but unfortunately we can't reproduce it - the problem seems to appear at random.

We've only seen the problem occur with MSIE 8.0 (Check for "Trident/4.0" on those IE7s you're seeing). 4k seem to be randomly removed from the page's markup, resulting in subsequent requests for invalid URLs since the HTML is messed up.

This has nothing to do with ASP.NET as we are seeing the same problem on two distinct servers:

• IIS 6 on Windows 2003 (keepalive off)
• Jetty 6.1.7 + Apache 2.2 on RHEL 5 (keepalive on)

The only things I can think of that these two have in common are:

1. The client is MSIE 8
2. The servers are behind a Cisco load balancer (CSS 11501)

Looks like a serious bug in MSIE 8 but I have no idea how to work around the problem.

Answer 2

Please ignore this answer as it does not contribute. Sadly, I can't seem to delete my own answer.

Answer 3

We, too, have the same problem. Our site is load balanced over 14 servers by a Citrix Netscaler. It has been for a long time, but these problems started recently. I don't know exactly when.

• The servers are Windows 2003, running ASP.NET on IIS6. Compiled against 3.5.
• IE8 seems to be the only client causing this error. It occurs on all pages.
• We are averaging about one error/minute.
• We can't reproduce it, and have no clues on how to move on.

Is there any more info out there?

Examples of broken url's:

/ScriptResource.axd?d=_WFIBFT6VnV8tWO4uBNcSB8alYe33BwH5sqe1vuQ0u9eqHSi1fum6L-8oY>    <script type=
/WebResource.axd?d=RoHfaR8Coz-XpWOFrNBU<li><a href=

Answer 4

We too have the same problem with two different ASP.NET applications on two different servers at two different customer's sites.

Both servers are Windows 2003 running ASP.NET 3.5 SP1 on IIS6.

Sample requests (same page but different RAW url:s using URL rewriting):

/WebResource.axd?d=ANpdqNBxu9b_NyZOE1---><div%20class=
/WebResource.axd?d=ANpdqNBxu9b_NyZOE1%20--><div%20class=

Browser is always IE8.

It seems that the missing block is always 4096 bytes long.

Answer 5

*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.

Answer 6

Interesting, however, I am not setting this tag at all and I still have the issue. I do have the following at the top of my page

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"&gt;
<meta name="verify-v1" content

Answer 7

hi all,

Adding the Content-Type: text/html; charset=utf-8 does not work for my website. We are still being flooded by the Invalid Viewstate error mails. Please help!

regards Harish

Answer 8

Has anyone heard anything about a fix? Is there someplace else we can look for information? Almost every error on our site is caused by IE8.

Answer 9

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!

Answer 10

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.

Answer 11

any news from IE8 team on the fix....my iis log is full of these messages...my network admin is on my back....

Answer 12

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>

Answer 13

any fix exists? im also having this problem