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.
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?
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.
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:
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:
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.
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.
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.
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
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.
andrew_
Member
104 Points
52 Posts
Wildcard Extensions, RewritePath and /jsdebug
May 22, 2007 03:59 PM|LINK
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?
Jin-Yu Yin -...
All-Star
21280 Points
1824 Posts
Re: Wildcard Extensions, RewritePath and /jsdebug
May 30, 2007 03:15 AM|LINK
Hi,
I fail to reproduce the issue. Can you show me your code?
Jin-Yu Yin
Microsoft Online Community Support
ced-2k
Member
2 Points
11 Posts
Re: Wildcard Extensions, RewritePath and /jsdebug
May 30, 2007 12:41 PM|LINK
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):
this must be placed in the "system.web" then "httpHandlers" section.
buddydvd2
Member
17 Points
15 Posts
Re: Wildcard Extensions, RewritePath and /jsdebug
Jun 07, 2007 08:03 AM|LINK
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
ajax JSON url rewriting ASP.NET 2.0 isapi extension wildcard extension mapping pathinfo iis 5.0
buddydvd2
Member
17 Points
15 Posts
Re: Wildcard Extensions, RewritePath and /jsdebug
Jun 08, 2007 08:10 AM|LINK
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:
This code inserts the missing logic using ASP.Net's HTTP Module framework.
This code is derived from djMax's post.
-David
andrew_
Member
104 Points
52 Posts
Re: Wildcard Extensions, RewritePath and /jsdebug
Jun 08, 2007 10:25 PM|LINK
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.
dunebuggy
Member
160 Points
42 Posts
Re: Wildcard Extensions, RewritePath and /jsdebug
Jun 09, 2007 12:16 AM|LINK
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.
buddydvd2
Member
17 Points
15 Posts
Re: Wildcard Extensions, RewritePath and /jsdebug
Jun 09, 2007 12:20 AM|LINK
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.
dunebuggy
Member
160 Points
42 Posts
Re: Wildcard Extensions, RewritePath and /jsdebug
Jun 09, 2007 12:23 AM|LINK
Here is the .vb we used, and included the tag in our web.config
Imports
SystemImports 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
Classdunebuggy
Member
160 Points
42 Posts
Re: Wildcard Extensions, RewritePath and /jsdebug
Jun 09, 2007 12:28 AM|LINK
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.