Controlling the interception of Javascript by js.axd

Feb 13, 2011 at 5:42 PM

Hi folks

I have a site into which I have blogEngine integrated, under a 'blog' subfolder so that I can use the blogEngine pages within the sites own masterpage. This works OK on the development web site, but when it is published to the production site, something rather odd happens to controls like LinkButton that use Javascript through webresource.axd. Because the web.config for the site needs to contain:

<add name="Javascript" path="js.axd" verb="*" type="BlogEngine.Core.Web.HttpHandlers.JavaScriptHandler, BlogEngine.Core" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode" />

to intercept Javascript for the blogEngine components, any existing LinkButtons in the site (not blogEngine related) cannot be clicked. Without the blogEngine httphandler shown above, the Linkbuttons behave as expected, with WebResource.axd called for the doPostback javascript that the LinkButton needs. But with the above handler, it looks like all requests to WebResouce.axd are intercepted by js.axd, and with the way my site is configured, this results in the doPostback not being carried out, even on pages for which no blogEngine components are used.

So the question is:

How can I restrict the 'scope' of the js.axd handler just to the blogEngine components, and to ensure that all non-blogEngine controls in the site are able to call WebResource.axd directly, without js.axd stepping in to intercept the calls for the non-blogEngine pages and controls?

Thanks if you can help me out with this.


Feb 14, 2011 at 5:54 PM

Alternatively, if this is not possible, is there anyway I can get the js.axd handler to be  used for https pages? At the moment it looks like vs.axd is not handling requests for WebResource.axd when they originate from a secure page. This is my original problem. Possibly it is because I have https dynamically served through the use of a 3rd party httpmodule (it is Ventaur.WebPageSecurity, though probably this in itself is not important?)


Feb 16, 2011 at 6:23 PM


I managed to sort this out in the end, but it looks like it wasn't the js.axd handler that was causing the trouble after all. I had to disable the HttpCompression module in blogEngine, after which it looks like WebResource.axd is now behaving itself. Is this likely to cause trouble later on? Is it acceptable just to miss the httpmodule entry for the compression module out of web.config, or will this disrupt the functioning of blogEngine?