ASP.NET Causing Corrupted HTML with WebResource.axd and ScriptResource.axd

Posted By: Tech Guy
Last Updated at 10:59 PM on Monday Oct 26, 2009
Found in: ASP.NET

If you found this page, most likely you have been seeing some strange things happening intermittently on your ASP.Net application.

It depends on what you track on your application, but most commonly you would see Invalid Viewstate or some 404 errors on your server logs that look very strange.

The common clue to this problem is that it always seem to focus around ScriptResource.axd and WebResource.axd. You can usually see these files included in the request string and sometimes paired with corrupted HTML from your page. Another clue is that it only happens for visitors using IE8.

At first glance the problem appears to be the result of a poorly written SPAM bot which is does a horrible job of parsing links out of HTML, but after some searching, the culprit is IE8 and it's Lookahead Downloader.

Yes, IE8 actually out of your page when it is rendered, and sometimes this affects the script links to your WebResource.axd and ScriptResource.axd files embedded in the page as well as various parts of JavaScript.

What is causing this is IE8's "Lookahead Downloader" which tries to speed up a users experience by pre-loading pages from links embedded in a page.

So is there a solution?

One solution put out there is to move the <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8"> meta tag from the HEAD of the page and sending the following HTTP response header:

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

In ASP.NET you can do this in the Page_Load of your page via:

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

Some have suggested that by not having the content type specified in the HEAD section it reduces the likelihood that the problem gets triggered. Keep in mind that some have tried this solution without success.

The last official word on this from MS on Oct 12, 2009:

We are closing this bug on the ASP.NET side because it is not an ASP.NET bug but instead is a bug with the IE 8 having issues with certain size buffer boundaries. The various workarounds that people have submitted are just changing the size of data (when in the stream headers are hit) which cause the effects to change. I want to note that this bug is being fixed on the IE side and we will come and update this connect bug when that happens.

So hopefully a definitive fix is coming soon.





Post a Comment

 


Name:


E-Mail:


Comments:  






Copyright 2017 Alter Procedure All Rights Reserved