Take the 2-minute tour ×

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

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?
share|improve this question
Update: The 4k bug is now fixed by the IE8 Cumulative update on 3/30/2010. blogs.msdn.com/ieinternals/archive/2010/04/01/… –  EricLaw Apr 1 '10 at 1:58
add comment

5 Answers

up vote 12 down vote accepted

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


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.


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.


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


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


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.

share|improve this answer
Setting an HTTP Header in IIS uses it for all requests, even for stylesheets and images. Is there a way to do this without setting it in IIS? –  goldenratio Jan 29 '10 at 18:34
You could use an ISAPI filter, or have your ASP/ASPX code add the header manually. However, as noted over on the IEInternals blog, we've determined that there are quite a few different ways to trigger the buggy behavior, and unfortunately pre-parser restart due to charset is only one of them. A fix is needed in the browser to really eliminate this problem. –  EricLaw Jan 29 '10 at 23:22
add comment

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!

share|improve this answer
add comment

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

<meta name="verify-v1" content
share|improve this answer
Please email me a network capture (see www.fiddlercap.com) –  EricLaw Jun 26 '09 at 17:50
We are seeing the same problem and we don't have a META HTTP-EQUIV. So far we can't figure out a pattern of when the problem occurs so it is hard to get a network capture. We have only seen it on IE8 PCs –  TonyB Jun 30 '09 at 1:29
If you send me the HTML source of the affected page (or the URL, if it's public), I may be able to help. Beyond the charset declaration, there are a few other things which will cause the pre-parser to restart, and one of those may be the factor here. –  EricLaw Jun 30 '09 at 23:20
is there an Email address i can contact you at? It is not a public site and I don't really want the full html online (intranet page). –  TonyB Jul 1 '09 at 18:30
More Info: I though I had the HTML that caused the problem but can't reproduce by just viewing that html in IE8. Could refreshing the page or an ajax query case the pre-parser to restart? The page in question has a bit of ajax going on so it is hard to reproduce exactly what is happening on the client. –  TonyB Jul 1 '09 at 18:36
show 1 more comment

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.

share|improve this answer
No luck - still having the issue. –  NickAtuShip Sep 21 '09 at 21:26
add comment

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.

    <meta http-equiv=Refresh content="0; URL=/ErrorPage.aspx?Error=NoJavascript">
share|improve this answer
add comment

Your Answer


