Wildcard Extensions, RewritePath and /jsdebug

What we have here is not an unusual situation, but not a common one.

We are using a wildcard extension mapping ".*" mapped to the asp.net (2.0) isapi library. We're doing this so that we can do UrlRewriting without using a seperate ISAPI extension and so that we can handle url rewrites on directories and configure the rewrites using the website's local web.config.

We have sections for exceptions on file extensions and directories, and overall this works really well... until we have to implement asp.net ajax.

Because asp.net ajax's ScriptManager defines the script in html as src="ws/WebService.asmx/jsdebug" IIS sends this request to ASP.NET, which then looks for that directory path, and naturally, it doesnt exist.

So it throws a nasty ASP.NET 404 error when attempting to view http://siteurl/ws/WebService/jsdebug.

I'm going to go out on a limb here and assume that whatever mechanism the asp.net ajax library is using to generate this javascript is being interrupted by all requests coming to the aspnet_isapi library. When I disable the wildcard extension mapping, everything works as it should.

ASP.NET AJAX Developers! How can I work around this limitation, using our current setup?

Re: Wildcard Extensions, RewritePath and /jsdebug

Hi,

I fail to reproduce the issue. Can you show me your code?

Re: Wildcard Extensions, RewritePath and /jsdebug

I am also using wildcard extension and UrlRewriting and I have no problem with that.

Maybe this is due to the fact that I added this line to my web.config (in order to solve another problem):

<add verb="*" path="*.js" type="System.Web.StaticFileHandler"/>

this must be placed in the "system.web" then "httpHandlers" section.

Re: Wildcard Extensions, RewritePath and /jsdebug

I'm experiencing the same exact problem. In fact, this problem even occurs when UrlRewriting.Net is disabled. I'm currently running ASP.NET 2.0 on Windows 2000 with IIS 5.0.

When I define the wildcard extension mapping, ScriptService URLs (e.g. xxxxx.asmx/js, xxxxx.asmx/jsdebug, and xxxxx.asmx/MethodName) all fail to work.

However, when I remove the wildcard mapping, everything works again.

One interesting I noticed is the way how IIS handle urls like "xxxxx.asmx/js" under the "no wildcard extension mapping" default IIS configuration.

For a URL like "xxxxx.asmx/js", I had expected it to fail under the default configuration since it should technically treat the URL as an extension-less url. Instead, it seems like IIS progressively traverse the path nodes and check to see if a node in the path resolves to an actual file. And if it does, it changes the requested path from "/xxxxx.asmx/js" to "/xxxxx.asmx" and stuffs the "/js" part as the "PathInfo" request header. (http://msdn2.microsoft.com/en-us/library/system.web.httprequest.pathinfo.aspx)

It seems like when wildcard extension mapping is turned on, IIS disables that behavior and forwards the request to ASP.net without parsing the requested path.

Does this make sense?

-David

Re: Wildcard Extensions, RewritePath and /jsdebug

I figured out why.

This misbehavior can be reproduced on IIS 5.0 (Windows 2000) and IIS 5.1 (Windows XP Pro). It does not effect VS's development server nor IIS 6.0.

When IIS 5.x sees a URL like this "/webservices/helloworld.asmx/js", it splits them into token and iterates through them from left to right. For each token, it checks to see if it ends as a string that matches an extension mapping. As soon as it finds it, it stops. At this point, before IIS forward the request to ASP.Net's ISAPI extension, it takes that finding and creates two server variables: URL and PATH_INFO.

For example, the following URL:

"/webservices/helloworld.asmx/js"

would cause IIS to define the following server variables:

SERVER_VARIABLE["URL"]: "/webservices/helloworld.asmx"
SERVER_VARIABLE["PATH_INFO"]: "/webservices/helloworld.asmx/js"

Similarly, a URL like this:

"/nonexistent.aspx/helloworld.asmx/js"

would cause IIS to define the following server variables:

SERVER_VARIABLE["URL"]: "/nonexistent.aspx"
SERVER_VARIABLE["PATH_INFO"]: "/nonexistent.aspx/helloworld.asmx/js"

When you turn on IIS 5.x wildcard extension mapping, this logic never gets executed. Instead, IIS defines the URL server variable the same way it defines PATH_INFO (i.e. nothing is stripped out).

ASP.Net does not like this. Without URL rewriting, ASP.Net doesn't know how to handle the request "/webservices/helloworld.asmx/js". Because of this, ASP.Net forwards the request to the FileNotFound http handler which displays the 404 error page we see.

Again, this only applies to IIS 5.x and not IIS 6.0. IIS 6.0 seems to have reworked this logic in the expected way.

To solve this problem, create a file called IIS5XWildCardExtensionFix.cs and place it in your App_Code folder:

using System;
using System.Web;


public class IIS5XWildCardExtensionFix : IHttpModule
{
    public IIS5XWildCardExtensionFix() { }


    public void Dispose() { }


    public void Init(HttpApplication context)
    {
        context.BeginRequest += new EventHandler(OnBeginRequest);
    }


    private void OnBeginRequest(object sender, EventArgs e)
    {
        HttpApplication app = sender as HttpApplication;
        HttpContext context = app.Context;
        string path = context.Request.Path;
        int asmx = path.IndexOf(".asmx/", StringComparison.OrdinalIgnoreCase);
        if (asmx >= 0)
            context.RewritePath(
                path.Substring(0, asmx + 5),
                path.Substring(asmx + 5),
                context.Request.QueryString.ToString());
    }
}

Add the following line to in your web.config file in the HttpModules tag:

<add name="IIS5XWildCardExtensionFix" type="IIS5XWildCardExtensionFix" />

This code inserts the missing logic using ASP.Net's HTTP Module framework.

This code is derived from djMax's post.

-David

Re: Wildcard Extensions, RewritePath and /jsdebug

Fantastic work. I really appreciate you diving into this logic and figuring out the problem. We are, in fact, running XP Pro on most of our development machines.

I'll be giving this fix a shot next week Monday and will report back with my findings.

Re: Wildcard Extensions, RewritePath and /jsdebug

I tried this solution without luck :\ Will create a new thread with the info.

Basically, removing the wildcard extension mapping fixes the issue, but we need to retain that mapping, so since adding it we are getting the 'Sys is undefined' error indicating the client is not receiving the .js file.

Re: Wildcard Extensions, RewritePath and /jsdebug

You don't have to remove the wildcard extension mapping. In fact, this code is meant to address the issue introduced by defining the wildcard extension mapping.

Re: Wildcard Extensions, RewritePath and /jsdebug

Here is the .vb we used, and included the tag in our web.config

Imports System
Imports System.Web
Imports Microsoft.VisualBasic

Public Class IIS5XWildCardExtensionFix
Implements IHttpModule

Public Sub New()
End Sub

Public Sub Dispose() Implements System.Web.IHttpModule.Dispose
End Sub

Public Sub Init(ByVal context As System.Web.HttpApplication) Implements System.Web.IHttpModule.Init
AddHandler context.BeginRequest, AddressOf OnBeginRequest
End Sub

Private Sub OnBeginRequest(ByVal sender As Object, ByVal e As EventArgs)
Dim app As HttpApplication = CType(sender, HttpApplication)
Dim context As HttpContext = app.Context
Dim path As String = context.Request.Path
Dim asmx As Integer = path.IndexOf(".asmx/", StringComparison.OrdinalIgnoreCase)
If (asmx >= 0) Then
context.RewritePath(path.Substring(0, asmx + 5), path.Substring(asmx + 5), context.Request.QueryString.ToString())
End If
End Sub

End Class

Re: Wildcard Extensions, RewritePath and /jsdebug

understood, thank you. We aren't able to remove the wildcard mapping which is why I am attempting this workaround. So far no luck, but thank you for your help thus far.

Re: Wildcard Extensions, RewritePath and /jsdebug

Are you guys stripping out ".asmx" during the URL rewriting process?

This will not work: http://yoursite.com/ws/WebService/jsdebug
This will work: http://yoursite.com/ws/WebService.asmx/jsdebug

What's the src attribute in your aspx page's script tag?

Re: Wildcard Extensions, RewritePath and /jsdebug

we are not actually rewriting urls, we are securing documents in particular directories using forms authentication. In order for this to work for documents other than aspx files, we needed to add the wildcard application mapping. I tried specifically granting access the ScriptResource.axd and WebResource.axd files in the web.config per other posts suggestions but nothing has yet worked. I can provide url if it's allowed, or email it...

Re: Wildcard Extensions, RewritePath and /jsdebug

buddydvd2

I'm experiencing the same exact problem. In fact, this problem even occurs when UrlRewriting.Net is disabled. I'm currently running ASP.NET 2.0 on Windows 2000 with IIS 5.0.

When I define the wildcard extension mapping, ScriptService URLs (e.g. xxxxx.asmx/js, xxxxx.asmx/jsdebug, and xxxxx.asmx/MethodName) all fail to work.

However, when I remove the wildcard mapping, everything works again.

One interesting I noticed is the way how IIS handle urls like "xxxxx.asmx/js" under the "no wildcard extension mapping" default IIS configuration.

For a URL like "xxxxx.asmx/js", I had expected it to fail under the default configuration since it should technically treat the URL as an extension-less url. Instead, it seems like IIS progressively traverse the path nodes and check to see if a node in the path resolves to an actual file. And if it does, it changes the requested path from "/xxxxx.asmx/js" to "/xxxxx.asmx" and stuffs the "/js" part as the "PathInfo" request header. (http://msdn2.microsoft.com/en-us/library/system.web.httprequest.pathinfo.aspx)

It seems like when wildcard extension mapping is turned on, IIS disables that behavior and forwards the request to ASP.net without parsing the requested path.

Buddydvd2. I think I have very similar problem you are experiencing, but littel different. Enabling IIS Wildcard makes Ajax Toolkit Slides control not working. I have posted the problem here, please take a look: http://forums.asp.net/t/1129701.aspx

I have tried to apply your logic to axd files, but that did not help

Please help anybody

Re: Wildcard Extensions, RewritePath and /jsdebug

buddydvd2

Are you guys stripping out ".asmx" during the URL rewriting process?

This will not work: http://yoursite.com/ws/WebService/jsdebug
This will work: http://yoursite.com/ws/WebService.asmx/jsdebug

What's the src attribute in your aspx page's script tag?

This is the source I have on my page for Slides Control in Ajax Toolkit:

Please help

Re: Wildcard Extensions, RewritePath and /jsdebug

Hi Rafal,

Try your solution on a machine with IIS 6 installed. The error you're getting is most likely caused by IIS 5.x. The error response you got, "HTTP verb POST not allowed", says that the request didn't even get routed to ASP.Net's ISAPI extension module yet.

Also, make sure you select "All verbs" in the extension mapping dialog for your wildcard mapping (i.e "*.").

Hope that helps,
Good luck.

-David

Re: Wildcard Extensions, RewritePath and /jsdebug

David,

You are absolutly right!!! I just notice I have IIS 5 installed. It works fine if I have wildcard ".*" disabled, but if I have it enabled I am getting

Java Script error:

HTTP verb POST used to access path '/mysite/SlideShow/Slideshow.aspx/getSlides is not allowed

I have tried your solution, but it does not work. I wonder if thsi has something to do with .axd files instead...

I do not have access to IIS 6 now... I will try to upgrade... I am not sure if IIS 6 is available on XP...

Re: Wildcard Extensions, RewritePath and /jsdebug

I did some more research and debugging. It seesm you are correct. The server variables are not set by IIS, because ASP.NET is in control.

The URL is: http://localhost/Ajax/SlideShow/SlideShow.aspx/GetSlides

PathInfo is empty string

I wonder maybe there is some way to write some generic code if the file does not exist than rewrite and fix PathInfo this way... But than there is a problem that there are rules in URLrewriter.net for some links without the existent path.

Maybe just setting PathInfo would help, without actual rewriting, so URLRewriter can do it...

Re: Wildcard Extensions, RewritePath and /jsdebug

In fact this was simple, I just copy your solution, but use it with aspx instead... :)

private void OnBeginRequest(object sender, EventArgs e)

{

HttpApplication app = sender as HttpApplication;

HttpContext context = app.Context;

string path = context.Request.Path;

int aspx = path.IndexOf(".aspx/", StringComparison.OrdinalIgnoreCase);if (aspx >= 0)

{

context.RewritePath(

path.Substring(0, aspx + 5),

path.Substring(aspx + 5),

context.Request.QueryString.ToString());

return;

}

int asmx = path.IndexOf(".asmx/", StringComparison.OrdinalIgnoreCase);if (asmx >= 0)

context.RewritePath(

path.Substring(0, asmx + 5),

path.Substring(asmx + 5),

context.Request.QueryString.ToString());

}

Re: Wildcard Extensions, RewritePath and /jsdebug

Cool. Glad that worked out for you. [:)]

Re: Wildcard Extensions, RewritePath and /jsdebug

This is a reply to the original topic in this thread...

The HttpModule posted 'sort of' works. It takes care of the Path issue for sure, but it still doesnt address another issue. Say you have a url like http://localhost/articles/157268/

Even though I have my service referenced defined as

<asp:ServiceReference Path="~/ws/PolMach.asmx" />

ASP.NET AJAX isn't rendering the path properly in html. In html it looks like this...

Which is incorrect. It ends up looking to articles/157268/ws/PolMach.asmx. I specified that it should use the file at the root, and it should be written to the page as such. Definately not using a relative path. Chalk this up as another issue overlooked by the devteam. Hopefully it'll be fixed down the road.

I have yet to find a dynamic and easily adaptable solution to this. I'll keep tinkering. If someone has some way to get ASP.NET to render that script tag as if it were looking to the root of the site I would really appreciate it if you would share :)

Edit: It's a very lame, but seemingly easy hack to fix this (hopefully only until the development team provides an actual fix) . I simply copied the output script tag for the webservice (which the ScriptManager generates), removed the service from the ScriptManager control in markup and then added the script tag for the service in the same place in html, prepending the '/' character to the src attribute. Seems to work OK, but is by no means a preferred way of making this work.

On a side note, I really wish there was some kind of a progress indicating blog/site which also included release date goals. Would make me feel warm and fuzzy.