WebResource.axd requested without parameters - Thi

问题:

I'm finding this problem every now and then in my production website, and it has me absolutely stumped...

My app works perfectly in both dev and production, but every now and then, I get an e-mail from my global error handling with this:

MESSAGE: This is an invalid webresource request.
URL: /WebResource.axd
(which means that for some reason webresource.axd was requested without specifying any GET parameters)

I'm not doing anything with webresource.axd myself, I don't get any of my resources through it, it's only used automatically by .Net to serve it's typical JS for validators, etc.

Any idea why this might be getting requested without parameters? Has anyone encountered this?

回答1:

That definitely is a bot not doing very good job of crawling your web site. It processes your web form and locates reference to WebResource.axd, for example:

<script src="/site/WebResource.axd?d=MtIW_TBRtZCvAXDMJGwg4g2&amp;t=633772897740666651" type="text/javascript"></script>

The bot expects static JavaScript files only and tries to download it by requesting WebResource.axd without parameters. The result is an exception thrown by System.Web.Handlers.AssemblyResourceLoader class and intercepted by Application_Error in Global.asax.

I believe this exception is harmless - the client will receive 404 error. You can safely ignore it.

回答2:

We also have all of our errors emailed to us, and we occasionally get those too. They never seem to have a referrer, and the user agent is usually a little wacky. We write them off as bots.

I just checked a couple of the offending client IP's against Arin, and one them belonged to a web-spidering-type organization, so there's a little more evidence for the bot theory.

回答3:

I would also log the useragent that made the request to WebResource.axd. It wouldn't surprise me if it was a bot crawling your site.

回答4:

This discussion...

http://www.telerik.com/community/forums/aspnet/spell/this-is-an-invalid-webresource-request.aspx

... and this linked MSDN article...

http://msdn.microsoft.com/en-us/magazine/cc163708.aspx

... might shed a little light (though not much).