在一个不稳定的无效的ViewState净的应用问题。 Erratic Invalid Viewstate issue in a .NET application

这似乎是很多人都经历了同样的IE8的问题。似乎发生的是，不知何故，IE8（在IE8的渲染模式和IE7兼容模式）将失去4096个字节的HTML文档中该数据缺失导致此异常（通常你看到这一scriptresource或WebResource呼叫）。这里有一个问题上，微软的错误报告：https://connect.microsoft.com/visualstudio/feedback/viewfeedback.aspx？feedbackid = 434997也有很多论坛，博客等职位，对这一问题：无效的参数产生webresource.axdIE 8滴内存页？http://forums.asp.net/t/1373410.aspx？页索引= 1http://forums.asp.net/p/1409964/3085329.aspx微软已经回答了这个问题：值得注意的是一个错误的Internet Explorer 8。Internet Explorer团队一直在调查这个问题。影响：到目前为止，我们相信问题在与Web应用程序的最终用户的体验没有影响；唯一的负面影响是虚假的或畸形的请求的JavaScript投机下载引擎发出。当脚本实际上是由解析器所需要的，它将被下载并使用当时。的情况下：虚假请求似乎只有在一定的时间的情况下，只有当元HTTP-EQUIV标记包含一个字符集指令内容类型出现在文档中，只有当一个JavaScript的HTTP URL跨越SRC响应体第四千零九十六字节。解决方法：因此，我们认为这个问题可以通过声明的网页使用的HTTP内容类型标头而不是指定页内的字符集的减轻。因此，而不是把
This appears to be the same IE8 issue that many people have been experiencing. What appears to happen is that somehow IE8 (in both IE8 rendering mode and IE7 compatibility mode) will lose 4096 bytes out of the middle of the HTML document and this missing data causes this exception (you usually see this in a ScriptResource or WebResource call). Here is a Microsoft bug report on the issue: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx? FeedbackID=434997 Also there are plenty of forum, blog etc posts on this issue: Invalid Webresource.axd parameters being generated IE 8 dropping memory pages? http://forums.asp.net/t/1373410.aspx? PageIndex=1 http://forums.asp.net/p/1409964/3085329.aspx Microsoft has responded to this issue: Note is a bug in Internet Explorer 8. 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 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: Hence, we currently believe this issue can 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">
在你的头上的标签，而不是发送HTTP响应标头后：
In your head tag, instead, send the following HTTP response header:
Content-Type: text/html; charset=utf-8
注意，在所有的浏览器性能改进的HTTP标头的结果字符集的规范，因为不需要重启浏览器的解析器解析从开始时遇到的字符集的宣言。此外，使用HTTP标头有助于减轻一定的XSS攻击载体。注：有报道说，这一问题仍然发生在元HTTP-EQUIV页上没有。我们会更新这个评论时，我们有了更多的调查。微软发布的6 / 30 / 2009在12:25 PM。编辑：
我仍然看到这个例外偶尔，但这个错误报告作为：http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx
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. NOTE: There have been reports that this problem still happens when the META HTTP-EQUIV is not on the page. We will update this comment when we have more investigation. Posted by Microsoft on 6/30/2009 at 12:25 PM. Edit:
I still see this exception occasionally, but this bug is reported as being fixed: http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx

來源：http://www.bluefaq.com/csharp/4398