原始问题:
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/WebResource.axd?d=D-wd7RbHCvSp /WebResource.axd?d=D-wd7RbHCvSp_
在某些情况下,垃圾是编码的JavaScript,我已经看到了网址的一部分...完全空的参数字符串...我没有看到明显的模式.
顺便说一下,如果它是相关的,应该注意的是,我不相信这个WebResource不是一个除了在页面上包含某些功能时由.NET自动包含的股票WebResource ......在这种情况下,一个字段验证器.查看实际WebResource.axd的内容,可以看到非常标准的Javascript函数集,这些函数似乎是为处理泛型.NET事件而设计的.不是我们创造的任何东西.
有没有人见过这样的东西?(或者更好,是否有人理解为什么会发生这种情况,并提出消除它的方法?)
编辑0:一些其他信息:
第1项:在回答一个答案时,我们确保我们的脚本包含CDATA标签,因为我们的doctype是xhtml transitional:
不幸的是,尽管我们寄予厚望,但它似乎并没有解决问题.我们已经更多地注意到IE 8作为一个浏览器,这可以让人相信这是与浏览器相关的想法...也许是浏览器解析流的方式......但为什么我们会得到微妙的不同响应随后的尝试让我感到困惑.
第2项:事实证明,省略的部分似乎是相当规则的块.有人报告说他看到丢失了1k或4k的区块,而我(到目前为止......我只看了两个案例)会同意(我的两个数据都丢失了4096字节).
根据这篇文章:
http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv
似乎问题是由于浏览器在未指定doctype时呈现页面的方式不同而引起的.
这是我在这个主题上发现的另一个有趣的帖子,但仍然不是解决方案:
http://blog.aproductofsociety.org/?p=11
在上面的页面上,它有"Response.Cache.SetNoStore()"作为评论中可能的解决方案,我将尝试下一步,看看它是否有帮助.
Microsoft已对此问题做出回应:
注意是Internet Explorer 8中的错误.Internet Explorer团队一直在调查此问题.
- =影响= - 到目前为止,我们认为该问题对最终用户使用Web应用程序的体验没有影响; 唯一的负面影响是JavaScript推测下载引擎发送的虚假/格式错误的请求.当解析器实际需要脚本时,它将在那时正确下载和使用.
- =环境= - 只有在文档中出现包含具有CHARSET指令的Content-Type的META HTTP-EQUIV标记时,并且仅当JavaScript SRC URL跨越4096th时,才会在某些时序情况下发生虚假请求HTTP响应主体的字节.
- =解决方法= - 因此,我们目前认为可以通过使用HTTP Content-Type标头声明页面的CHARSET而不是在页面中指定它来减轻此问题.
所以,而不是放
[META HTTP-EQUIV ="Content-Type"CONTENT ="text/html; charset = utf-8"]
相反,在头标记中,发送以下HTTP响应标头:
内容类型:text/html; 字符集= utf-8的
请注意,HTTP标头中的charset规范可以提高所有浏览器的性能,因为浏览器的解析器在遇到字符集声明时无需从头开始重新解析.此外,使用HTTP标头有助于缓解某些XSS攻击媒介.
注意:有报告称,当页面上没有META HTTP-EQUIV时,仍会出现此问题.当我们进行更多调查时,我们会更新此评论.微软于2009年6月30日下午12:25发布