生成无效的 Webresource.axd 参数
原始问题：
WebResource.axd url 生成出现奇怪的错误。 （它似乎与相当常见的“WebRsource.axd Padding 无效且无法删除”问题无关）。
我们有一个 ASP.NET 网页，在创建时会添加对 WebResource.axd 的脚本引用。
在这种情况下，我们看到 WebResource.axd 链接偶尔会在超过某个点后变成垃圾，并被看起来像 JavaScript 的内容所取代。 更糟糕的是，url 生成失败似乎不一致。
在我们的例子中，链接应该（通常确实看起来像）：
/WebResource.axd?d=D-wd7RbHCvSp_p0mHAmE4g2&t=633464867255568315
一切都很好。 然而，我们收到了用户记录的错误...他们尝试访问的 url 看起来像（在一种情况下）：
/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，我已经看到了 url 的一部分...完全空的参数字符串...我没有看到明显的模式。
顺便说一句，如果它是相关的，应该指出的是，我不相信这个 WebResource 是一个股票 WebResource，当页面上包含某些功能时，.NET 自动包含该 WebResource...在这种情况下，一个字段验证器。 查看实际 WebResource.axd 的内容会发现看起来非常标准的 Javascript 函数集，这些函数似乎是为处理通用 .NET 事件而设计的。 不是我们创造的任何东西。
有人见过这样的东西吗？ （或者更好的是，有没有人理解为什么会发生这种情况，并想出一种方法来消除它？）
编辑0：一些附加信息：
第1项：针对一个答案，我们确保我们的脚本是用 CDATA 标签封装的，因为我们的 doctype 是 xhtml 过渡的：
<!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 字节的数据）。
Original Question:
We have an odd error with WebResource.axd url generation. (It does not seem to be related to the fairly common "WebRsource.axd Padding is invalid and cannot be removed" issue).
We have an ASP.NET web page that, when created, adds a script reference to WebResource.axd.
In this case, we're seeing that the WebResource.axd link occasionally turns into garbage past a certain point, replaced by what looks like javascript. Worse yet, the url generation failure seems to be inconsistant.
In our case, the link should (and usually does look like):
/WebResource.axd?d=D-wd7RbHCvSp_p0mHAmE4g2&t=633464867255568315
All well and good. However, we are getting errors logged from users...and the url they're trying to access looks like (in one case):
/WebResource.axd?d=D-wd7RbHCvS/../../images/icons/Ico_resize.gif')}}function%20ShowFilter_Manufacturer(){var%20div.......
[the remaining encoded javascript from that link has been removed as irrelevant]
Stranger yet, we got a few of these in rapid succession from the same user, who was apparently trying to reload the page...each url slightly different.
/WebResource.axd?d=D-wd7RbHCvS<garbage>
/WebResource.axd?d=D-wd7RbHCvSp<garbage>
/WebResource.axd?d=D-wd7RbHCvSp_<garbage>
In some cases the garbage is encoded JavaScript, I've seen portions of a url...completely empty parameter strings...I don't see an obvious pattern.
As an aside, should it be relevant, it should be noted that I don't believe that this WebResource is anything other than a stock WebResource that is automatically included by .NET when certain features are included on a page...in this case, a field validator. Looking at the contents of the actual WebResource.axd reveals very standard looking set of Javascript functions that seem designed to handle generic .NET events. Not anything we've created.
Has anyone seen anything like this? (or better, has anyone understood why this was happening, and come up with a way to eliminate it?)
EDIT 0: Some additional information:
Item 1: In response to one answer, we made sure that our scripts are encased with CDATA tags, since our doctype is xhtml transitional:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Unfortunately, though we had high hopes, it does not seem to have solved the problem. We've noticed this more often with IE 8 as a browser, which would lend some credence to the idea that this is browser related...perhaps the way the browser is parsing the stream...but why we would get subtly different responses on subsequent attempts baffles me.
Item 2:
It turns out that the omitted sections seem to be blocks of fairly regular size. Someone reported that he was seeing 1k or 4k blocks missing, and I (so far...I've only looked at two cases thus far) would agree (mine were both missing 4096 bytes of data).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
您是否在 Web 配置中注册了任何 HttpHandler 或模块，可以在将呈现的 HTML 发送给用户之前对其进行修改？
这些通常可以是：
可能值得一看。
Have you got any HttpHandlers or Modules that are registered in the web config that modify the rendered HTML before it's sent to the user?
These can often be:
Might be worth a look.
这是一篇旧帖子...但我通过谷歌搜索发现并提醒了我这一点...
http://www.troyhunt.com/2010/09/fear-uncertainty-and-and-padding-oracle.html
可能是有关的？
This is an old post... but I've came across through a google search and reminded me of this...
http://www.troyhunt.com/2010/09/fear-uncertainty-and-and-padding-oracle.html
Could it have been related?
Microsoft 最终修复了此问题：
http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx
This was eventually fixed by Microsoft:
http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx
我来自 ASP.NET 团队 - 我们正在寻找愿意与我们合作研究此问题的客户。 如果有人能够通过请求自己的页面并检查日志来可靠地重现问题，并且愿意与我们的支持小组合作，请回复或直接向我发送消息。 谢谢！
I am from the ASP.NET team -- we are looking for a customer willing to work with us on researching this issue. If anyone is able to reliably reproduce the problem by requesting their own pages and checking the logs, and is willing to work with our support group, please respond or send me a direct message. Thanks!
您正在针对什么版本的 .NET 进行编译？ 如果您将构建更改为旧版本或新版本，会发生什么？ （不确定这是否会做任何事情，但值得一试）
如果仍然发生，我认为您应该在 微软连接。 他们应该很快就会回复您。
What version of .NET are you compiling against? What happens if you change your build to build for an older or newer version? (not sure if this would do anything but it's worth a try)
If it's still happening, I think you should post a bug about it on Microsoft Connect. They should come back to you pretty quickly.
微软已针对此问题做出回应：
注意是 Internet Explorer 8 中的一个错误。Internet Explorer 团队一直在调查此问题。
-=影响=- 到目前为止，我们认为该问题对最终用户的 Web 应用程序体验没有影响； 唯一的负面影响是 JavaScript 推测下载引擎发送的虚假/格式错误的请求。 当解析器实际需要该脚本时，它将被正确下载并使用。
-=情况=- 虚假请求似乎仅在某些计时情况下发生，仅当包含带有 CHARSET 指令的 Content-Type 的 META HTTP-EQUIV 标记出现在文档中时，并且仅当 JavaScript SRC URL 跨越第 4096 个时才会发生HTTP 响应正文的字节。
-=解决方法=- 因此，我们目前认为可以通过使用 HTTP Content-Type 标头声明页面的 CHARSET 而不是在页面内指定它来缓解此问题。
因此，不要将
[META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8"]
放在 head 标记中，而是发送以下 HTTP 响应标头：
Content-Type: text/ html； charset=utf-8
请注意，HTTP 标头中的字符集规范会提高所有浏览器的性能，因为浏览器的解析器在遇到字符集声明时不需要从头开始解析。 此外，使用 HTTP 标头有助于减轻某些 XSS 攻击媒介。
注意：有报告称，当页面上没有 META HTTP-EQUIV 时，此问题仍然会发生。 当我们进行更多调查时，我们将更新此评论。
Microsoft 发布于 2009 年 6 月 30 日 12:25
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"]
In your head tag, instead, send the following HTTP response header:
Content-Type: text/html; charset=utf-8
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
根据这篇文章：
http://bytes. com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv
看来问题是由于未指定 doctype 时浏览器渲染页面的方式不同引起的。
这是我在这个主题上发现的另一篇有趣的文章，但仍然不是解决方案：
http://blog.aproductofsociety .org/?p=11
在上面的页面上，它在评论中将“Response.Cache.SetNoStore()”作为可能的解决方案，接下来我将尝试这个，看看是否有帮助。
according to this post:
http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv
It seems that the problem is caused by the way browsers render pages differently when the doctype is not specified.
Here is another interesting post i found on this subject, still not the solution though:
http://blog.aproductofsociety.org/?p=11
on the above page it has "Response.Cache.SetNoStore()" as a possible solution in the comments, i'll try this next to see if it helps.