原始问题：
我们对WebResource.axd url生成有一个奇怪的错误。 （它似乎与相当常见的“WebRsource.axd Padding无效且无法删除”问题有关。）
我们有一个ASP.NET网页，在创建时，会向WebResource.axd添加一个脚本引用。
在这种情况下，我们看到WebResource.axd链接偶尔会变成垃圾超过某个点，取而代之的是看似javascript的东西。更糟糕的是，网址生成失败似乎是不一致的。
在我们的例子中，链接应该（通常 看起来像）：
/WebResource.axd?d=D-wd7RbHCvSp_p0mHAmE4g2&t=633464867255568315
一切都很好。但是，我们收到用户记录的错误...以及他们尝试访问的网址（在一种情况下）：
/WebResource.axd?d=D-wd7RbHCvS/../../images/icons/Ico_resize.gif')}}function%20ShowFilter_Manufacturer(){var%20div.......
[该链接中剩余的已编码的javascript已被删除为无关]
更奇怪的是，我们从同一个用户那里快速连续获得了其中的一些用户，他们显然正在尝试重新加载页面...每个网址略有不同。
/WebResource.axd?d=D-wd7RbHCvS<garbage>
/WebResource.axd?d=D-wd7RbHCvSp<garbage>
/WebResource.axd?d=D-wd7RbHCvSp_<garbage>
在某些情况下，垃圾是编码的JavaScript，我已经看到了网址的一部分......完全空的参数字符串...我没有看到明显的模式。
顺便说一下，如果它是相关的，应该注意的是，我不相信这个WebResource不是一个除了.NET自动包含的股票WebResource，当某些功能包含在页面上时......在这种情况下，一个字段验证器。查看实际WebResource.axd的内容，可以看到非常标准的Javascript函数集，这些函数似乎是为处理泛型.NET事件而设计的。不是我们创造的任何东西。
有没有人见过这样的东西？ （或者更好，是否有人理解为什么会发生这种情况，并提出消除它的方法？）
编辑0：其他一些信息：
第1项：在回答一个答案时，我们确保我们的脚本包含CDATA标签，因为我们的doctype是xhtml transitional：
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
不幸的是，尽管我们寄予厚望，但它似乎并没有解决问题。我们已经更多地注意到IE 8作为一个浏览器，这可以让人相信这是与浏览器相关的想法...也许是浏览器解析流的方式......但为什么我们会得到微妙的不同响应随后的尝试让我感到困惑。
第2项： 事实证明，省略的部分似乎是相当规则的块。有人报告说他看到丢失了1k或4k的区块，而且我（到目前为止......我只看了两个案例）会同意（我的数据都丢失了4096字节）。
答案 0 :(得分：7)
根据这篇文章：
http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv
似乎问题是由于浏览器在未指定doctype时呈现页面的方式不同。
这是我在这个主题上发现的另一个有趣的帖子，但仍然不是解决方案：
http://blog.aproductofsociety.org/?p=11
在上面的页面上，它有“Response.Cache.SetNoStore（）”作为评论中可能的解决方案，我将尝试下一步，看看它是否有帮助。
答案 1 :(得分：5)
Microsoft已回应此问题：
注意是Internet Explorer 8中的错误.Internet Explorer团队一直在调查此问题。
- =影响= - 到目前为止，我们认为该问题对最终用户使用Web应用程序的体验没有影响;唯一的负面影响是JavaScript推测下载引擎发送的虚假/格式错误的请求。当解析器实际需要脚本时，它将在那时正确下载和使用。
- =情况= - 只有在文档中出现包含带有CHARSET指令的Content-Type的META HTTP-EQUIV标记时，且仅在JavaScript SRC URL出现时，虚假请求才会出现在某些时序情况下跨越HTTP响应主体的第4096个字节。
- =解决方法= - 因此，我们目前认为可以通过使用HTTP Content-Type标头声明页面的CHARSET而不是在页面中指定它来减轻此问题。
所以，而不是把
[META HTTP-EQUIV =“Content-Type”CONTENT =“text / html; charset = utf-8”]
在head标签中，发送以下HTTP响应标头：
Content-Type：text / html;字符集= UTF-8
请注意，HTTP标头中的charset规范可以提高所有浏览器的性能，因为浏览器的解析器在遇到字符集声明时无需从头开始重新解析。此外，使用HTTP标头有助于缓解某些XSS攻击媒介。
注意：有报告称当页面上没有META HTTP-EQUIV时仍会出现此问题。当我们进行更多调查时，我们会更新此评论。 由Microsoft于2009年6月30日下午12:25发布
答案 2 :(得分：2)
我来自ASP.NET团队 - 我们正在寻找愿意与我们合作研究此问题的客户。如果有人能够通过请求他们自己的页面和检查日志来可靠地重现问题，并且愿意与我们的支持小组合作，请回复或直接给我发送消息。谢谢！
答案 3 :(得分：1)
您正在编译哪个版本的.NET？如果您更改构建以构建旧版本或更新版本会发生什么？ （不确定这会做什么，但值得一试）
如果它仍在发生，我认为你应该在Microsoft Connect上发布一个关于它的错误。他们应该很快回复你。
答案 4 :(得分：1)
您是否有任何在Web配置中注册的HttpHandlers或模块，它们在将呈现的HTML发送给用户之前修改它？
这些通常可以是：
可能值得一看。
答案 5 :(得分：0)
这是一篇很老的帖子......但我通过谷歌搜索遇到了这个问题并提醒了我...
http://www.troyhunt.com/2010/09/fear-uncertainty-and-and-padding-oracle.html
它可能有关系吗？
答案 6 :(得分：0)