当前位置:  开发笔记 > 编程语言 > 正文

生成的Webresource.axd参数无效

如何解决《生成的Webresource.axd参数无效》经验,为你挑选了2个好方法。

原始问题:

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字节).



1> John Boker..:

根据这篇文章:

http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv

似乎问题是由于浏览器在未指定doctype时呈现页面的方式不同而引起的.

这是我在这个主题上发现的另一个有趣的帖子,但仍然不是解决方案:

http://blog.aproductofsociety.org/?p=11

在上面的页面上,它有"Response.Cache.SetNoStore()"作为评论中可能的解决方案,我将尝试下一步,看看它是否有帮助.



2> Jim Petkus..:

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发布

推荐阅读
有风吹过best
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有