[2005] Issues with re-writing URLs and Global.asax

[Kasracer]

So I setup Global.asax to manage my URLs and it works great in my development environment (running on the Visual Studio server) but when I publish the site and place it under IIS (IIS 7; Vista) to test it, it doesn't seem to work at all.

Is there something I'm missing?

All of my URL re-writing is done in the Application_BeginRequest event using Context.RewritePath.

Small snippet:

List<string> Args = new List<string>(HttpContext.Current.Request.Path.Split('/'));
            Args.RemoveAll(EmptyString);
            if (Args.Count > 0)
            {
                switch (Args[0].ToUpper())
                {
                    case "ABOUT":
                        Context.RewritePath("/Pages/About.aspx");
                        break;
                 }
            }

Would it be better to convert to using an Http Handler?

[shakti5385]

This will help you.

[Kasracer]

Hmm, I briefly looked through but most of the items talking about Global.asax are doing the exact samething.

But I just realized that going to \About\ would not pass through the .Net handler. I need to make an entry into IIS to have .Net process everything to do this. Makes sense but makes me think that an Http handler would be a better way to go.

[mendhak]

So I setup Global.asax to manage my URLs and it works great in my development environment (running on the Visual Studio server) but when I publish the site and place it under IIS (IIS 7; Vista) to test it, it doesn't seem to work at all.

Is there something I'm missing?

All of my URL re-writing is done in the Application_BeginRequest event using Context.RewritePath.

Small snippet:

List<string> Args = new List<string>(HttpContext.Current.Request.Path.Split('/'));
            Args.RemoveAll(EmptyString);
            if (Args.Count > 0)
            {
                switch (Args[0].ToUpper())
                {
                    case "ABOUT":
                        Context.RewritePath("/Pages/About.aspx");
                        break;
                 }
            }

Would it be better to convert to using an Http Handler?

Not so fast. Test it out first.

Go to the web project properties and assign to a virtual directory under IIS (or let VS create the virtual directory for you). See if it works.

Then, another small test - modify your hosts file to make localhost.whatever.com point to 127.0.0.1, make a new Web Site in IIS, point it to the directory where your files are and attempt to browse to it while VS is running so that you can debug and look at the values coming in, while at the same time emulating the 'test' conditions as closely as possible.

[Kasracer]

Unfortunately I cannot use the "Use Local IIS Web server" option because it states I need to have IIS 6 installed. I am currently running this on my Vista machine which has IIS 7 installed.

That's odd that Visual Studio 2008 (this is a 2.0 project though) can't use IIS 7.

I'm thinking about temporarily deploying this to my IIS 6 web server just to test.

Edit: Just ran a test under IIS 6 and it also does not work there (this is in a production environment; can't hook Visual Studio to it).

[mendhak]

Under the same conditions (IIS 7, VS 2008, .NET 2.0), I was able to get it to create a virtual directory in IIS.

Even if that isn't working for you, you should still be able to create a new website in IIS, with the headers mentioned earlier, and point it to the folder where your files are. Run the application (with VS's own web server) and then open a new browser window and browse to it using the new host headers, it should still hit breakpoints.

[Kasracer]

Ah I understand now. I'll take a look. Thanks

[mendhak]

Good luck. I await your observations with baited breath.

[Kasracer]

Okay that didn't do anything. As I figured, the ASP.Net engine doesn't parse any non-.Net specified files so there is absolutely nothing to debug (just a 404, nothing else). I'll just have to work on an HttpHandler solution. Oh well. Not sure how anyone is actually getting Global.aspx working unless they're re-writing .aspx urls (which seems kind of silly to me).

Edit: Looks like what I want to do is not possible unless I modify the IIS configuration and install some sort of custom handler (which is not what I wanted to do). Even implementing an IHttpHandler interface does not work as every request [i]has[/] to have an ASP.Net extension.

So, basically, converting the path www.mysite.com/Test.aspx to www.mysite.com/Test/ is not possible without IIS modifications.

Is this correct? Every article I seem to come across only discusses url re-writing to custom addresses that end in .aspx.

[mendhak]

I see, I didn't know you were trying out extensionless URL rewriting. You said you're using IIS 7, so this task should be easier for you. Create your HTTP Handler, add it to the <module> section in web.config as you normally would. Add the runAllManagedModulesForAllRequests attribute to modules and set it to true. That should hit the processrequest method in your handler (or its equivalent).

[Kasracer]

I'll check that out. What about IIS 6? I am developing this on a machine with IIS 7 but my environment for deployment will be IIS 6.

[mendhak]

For IIS 6, there are a few 'hacks' to make extensionless rewriting work. If you're working on an SEO oriented website, you will need to use a third party ISAPI DLL or use IIS 6 Wildcard Mapping. If you don't give a rat's posterior about proper headers, then you can go for the "404 rewriting" method, which is a bad idea; I mean, come on... 404 and then a redirect?

Of the two 'proper' methods, the third-party DLL would be more efficient. And if you've got the time and are hardcode, you can write your own ISAPI DLL, but it will have to be in VC++ or VB6, not in .NET. The reason you have to go through this grief is because IIS 6 obviously doesn't support extensionless rewriting, and the production environment is more important than development.