正在生成无效WebResource.axd的参数 [英] Invalid Webresource.axd parameters being generated

查看:241
本文介绍了正在生成无效WebResource.axd的参数的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

原题:

我们有WebResource.axd的URL生成一个奇怪的错误。 (这似乎并没有被涉及到相当普遍的WebRsource.axd填充是无效的不能删除的问题)。

我们有一个ASP.NET网页,创建时,增加了一个脚本参考WebResource.axd的。

在这种情况下,我们看到了WebResource.axd的链接偶尔会变成垃圾过去的某一点,通过什么样子的JavaScript取代。更糟糕的是,该URL生成失败似乎是不一致的。

在我们的例子中,链路应该(而且通常的的样子):

  /WebResource.axd?d=D-wd7RbHCvSp_p0mHAmE4g2&t=633464867255568315

都很好。但是,我们得到来自用户的错误记录......和他们试图访问的URL看起来像(在一种情况下):

<$p$p><$c$c>/WebResource.axd?d=D-wd7RbHCvS/../../images/icons/Ico_resize.gif')}}function%20ShowFilter_Manufacturer(){var%20div.......

[剩余的途中从该链接codeD的JavaScript已被移除无关]

陌生人呢,我们得到了其中的几个快速连续从相同的用户,谁显然试图重新加载网页...每个URL稍有不同。

  /WebResource.axd?d=D-wd7RbHCvS<garbage>
/WebResource.axd?d=D-wd7RbHCvSp<garbage>
/WebResource.axd?d=D-wd7RbHCvSp_<garbage>

在某些情况下,垃圾EN codeD的JavaScript,我见过一个url的部分...完全空的参数字符串...我没有看到一个明显的模式。

顺便说一句,它应该是相关的,应该指出的是,我不相信这是WebResource以外的任何其他股票WebResource,当某些功能都包含在页面上会自动包含.NET ...在这种情况下,一个字段验证器。纵观实际WebResource.axd的内容揭示了非常标准的寻找一套,似乎旨在处理通用.NET事件的JavaScript功能。没有什么,我们已经创建。

有没有人见过这样的事? (或更好的,有没有人知道这是为什么发生的事情,并想出了一个方法来消除它?)

编辑0:一些额外的信息:

项目1:针对一​​个答案,我们确保我们的脚本是用包裹标签CDATA,因为我们的doctype是XHTML过渡:

 &LT;!DOCTYPE HTML PUBLIC -  // W3C // DTD XHTML 1.0过渡// ENhttp://www.w3.org/TR/xhtml1/DTD/ XHTML1-transitional.dtd&GT;

不幸的是,虽然我们有很高的期望,它似乎并没有已经解决了这个问题。我们注意到与IE 8这更常作为浏览器,这将给予一些可信的想法,这是浏览器相关的...也许是这样的浏览器解析流...但为什么我们会得到微妙的不同反应随后尝试令我感到困惑。

第2项:
事实证明,被省略的部分似乎是相当正常大小的块。有人报告说,他是看到1K或4K块失踪,我(目前为止......我只在2箱子看着迄今)会同意(我也不见了4096字节的数据)。


解决方案

这最终被微软修复:

http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx

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&amp;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).

解决方案

This was eventually fixed by Microsoft:

http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx

这篇关于正在生成无效WebResource.axd的参数的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆