I've noticed the problem, but it isn't related to webresource.axd.

It just happens that most of the people won't log 404 errors or won't realize about this specific issue, but the fact is that somehow, sometimes, IE8 is eating away part of the page and requests resources from the server starting with part of a real url and finishing with some garbage from some point later in the page.

May be linked to the problem: http://stackoverflow.com/questions/835130/ie-8-dropping-memory-pages

Confirmed in one of my sites. Sometimes, 4K of the page get dropped and that cause very odd problems.

There's no known workaround for this problem. Please investigate and publish a patch as soon as you can, as it's a major problem.

What is Microsoft's answer to this? I see no comments here and I believe this to be a major issue.

I've also noticed this problem.

But there is still no solution found?

COMMON MICROSOFT.....THIS BUG HAS NOW BEEN KNOWN FOR A WHILE...WHEN IS THE FIX COMING. MY IIS LOG IS FULL OF THIS ERROR MESSAGE. ANY DATES FOR THE FIX YET????????

Hi, Eric Lawrence from the Internet Explorer team here. The Internet Explorer team has been investigating this issue and has constructed a reliable repro which mimics the obscure set of factors needed to cause this problem in IE8.

It is worth mentioning that anyone who is experiencing a problem here in IE6/IE7 or Firefox is encountering a different problem that is not related to the IE8 issue described below.

-=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 believe this issue can be mitigated by avoiding constructs that cause a restart of the parser. The most common cause of restarts is specification of the CHARSET in a META tag. (There are other, more obscure causes of restarts, but the CHARSET is believed to be the most common).

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.

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.

-=Future=-
The IE team will continue our investigation into this issue and may elect to make available an update for IE8 to correct this problem.

thanks!

Microsoft responded to the problem in the remarks. [See below]

There's a workaround for most of the situations (see top of page). Bad download links don't modify the way the good javascript is loaded into the page. This is a extra unusefull request, as it seems. This problem is thus not as important as we initially thought.

The workaround does not address or fix my problem. I do not include the <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8"> tag in my pages, but apparently, IIS automatically adds the Content-Type    : text/html; charset=utf-8 header to the response because I see that in the response headers.

But I still see this error showing up on my site when users are using IE8

Microsoft could you provide a list of other things to avoid that cause pre-parser restarts, so we can try to avoid these where possible?

Eric-
can we get a more exhaustive list of tags which cause the pre-parser to reset?

Hi,

As noted in the community discussion by Eric, we are investigating this issue. We do have a blog on this topic at http://blogs.msdn.com/ieinternals/archive/2009/07/27/Bugs-in-the-IE8-Lookahead-Downloader.aspx.

If you need assistance for a solution, we can provide advanced support through our normal support channel at http://support.microsoft.com/gp/advancedef/. Charges are refunded if the problem was caused by a bug in our product.

Kind Regards,
IE Team

Hi, Eric Lawrence from the Internet Explorer team here. The Internet Explorer team has been investigating this issue and has constructed a reliable repro which mimics the obscure set of factors needed to cause this problem in IE8.

It is worth mentioning that anyone who is experiencing a problem here in IE6/IE7 or Firefox is encountering a different problem that is not related to the IE8 issue described below.

-=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 believe this issue can be mitigated by avoiding constructs that cause a restart of the parser. The most common cause of restarts is specification of the CHARSET in a META tag. (There are other, more obscure causes of restarts, but the CHARSET is believed to be the most common).

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.

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.

-=Future=-
The IE team will continue our investigation into this issue and may elect to make available an update for IE8 to correct this problem.

thanks! Posted by EricLaw [MSFT] on 7/8/2009 at 5:33 PM