locked
Extending IIS to enable URL Rewriting in ASP.NET applications RRS feed

  • Question

  • User693847480 posted

    Hi,

    In researching URL rewriting in ASP.NET I have read that the reason ASP.NET 2.0 does not offer more support for URL rewriting is that this would be deprecated or rendered obsolete by the introduction of IIS7.  That said I can’t seem to find anything specifically about URL rewriting in IIS7, other than statements that it could be accomplished by using .NET code to extend IIS7.  Is there any documentation or articles available that may clarify this for me?

    Specifically, when trying to accomplish URL rewriting in ASP.NET it seems impossible to maintain postback functionality and the friendly url without either writing a custom form tag or using PageParser.GetCompiledPageInstance(), which is not supported for use outside the framework.

    Any information would be greatly appreciated. 

    Thanks,
    Karl 

    Monday, October 2, 2006 12:09 AM

All replies

  • User1902324039 posted

    Hi Karl,

    I'm having similar difficulties finding information about url rewriting in IIS7. I'm keen to see what responses you get, and I don't want to hijack the thread, but I'd also settle for being able to get the old style of url rewriting working.

    Currently we have an application that achieves URL rewriting in IIS5 and IIS6 by using a wildcard application mapping to .NET and we have an HttpModule which calls HttpContext.RewritePath when the HttpApplication.BeginRequest event is fired. To get postback's working we have our own class derived from Page which overrides the Render method and uses our own HtmlTextWriter which corrects the url in the form tag. It's actually quite easy once you figure it out and it seems to work really well now in both IIS5 and IIS6.

    With IIS7 (Vista RC1 build 5600) I realised that we could do away with the wildcard application mapping since our HttpModule would now be able to catch all requests. I've got this working, but it seems that when IIS Core chooses the HttpHandler it doesn't use the rewritten url.

    here is an example project for you to see what I'm talking about http://nate.deepcreek.org.au/download/SampleUrlRewriter.zip (6 KB)
    You should be able to just unzip it and point a website with a .NET 2.0 integrated App Pool at it to get it up and running.

    requesting http://localhost/database/file1.gif unexpectedly produces a 404 from the StaticFile handler even though the Requested URL is correctly rewritten.

    HTTP Error 404.0 - Not Found
    Description: The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
    Error Code: 0x80070002
    Notification: MapRequestHandler
    Module: IIS Web Core
    Requested URL: http://test/Default.aspx?database=%2fdatabase%2fmygif.gif
    Physical Path: D:\Dev\CS\ExampleRewritePath\database\mygif.gif
    Logon User: Anonymous
    Logon Method: Anonymous
    Handler: StaticFile

    If you request http://test/Default.aspx?database=%2fdatabase%2fmygif.gif then it works fine

    Aside from the wrong handler being used after the RewritePath the other thing i noticed is that the Physical Path was not updated to match the new url.
    To test this further, i caught the HttpApplication.MapRequestHandler event in my HttpModule and used the debugger to see the HttpRequest.PhysicalPath value. It had changed correctly to match the new url, so it would seem that the physical path in iis core is not getting updated to match the changed path in .NET. Could this be the reason that IIS Core is incorrectly choosing the StaticFile handler instead of the *.aspx handler, or is there something else I should be doing?

    Cheers,
    Nate

    Tuesday, October 3, 2006 10:19 PM
  • User209782248 posted

    Unfortunately, a couple things are still pretty hard to do in the Integrated mode, and remapping the handler based on a Rewrite is one of them.  Without boring you with technical details (about which you should be able to read about in my future blog post), here is how you can work around this limitation:

    1. Enable all ASP.NET modules to run for all requests by setting:
    <modules runAllManagedModulesForAllRequests="true" />

    NOTE: This will basically ignore the preCondition=managedHandler configuration for the default managed modules in the app, allowing all of them to run for all requests.  You may experience a performance hit for static files, but it may not be significant if most of your content is ASP.NET based as is.

    2. Make sure that your module is running prior to MapRequestHandler (realistically, in PostAuthorizeRequest or before) to do the RewritePath call.

    Let me know if this doesnt work for you.  As I said, I will try to blog about Rewriting in ASP.NET 2.0 / IIS7 and various options you have there.  This will be on www.mvolo.com.

    Thanks,

    Thursday, October 5, 2006 2:57 AM
  • User1902324039 posted

    Thanks Mike.

    runAllManagedModulesForAllRequests="true" has done the trick.

    I had tried removing the managedHandler preCondition from all the managed modules but that didn't work. It seems the runAllManagedModulesForAllRequests switch does something extra that allows the rewrite to work.

    I look forward to your blog entry. It'll be good to hear about what other rewriting options we have.

    Also, i was curious about the UrlMappingsModule that is added by default. Is that something to do with rewriting, or something different. Searching the web has not turned up any information about it. Perhaps that's something that will be included in your blog entry.

    Cheers,
    Nate

    Thursday, October 5, 2006 10:02 PM
  • User209782248 posted

    Yeah, the runAllManagedModulesForAllRequests is special.  More in blog post as soon as I get to it.

    The UrlMappingsModule is an ASP.NET 2.0 feature for limited url rewriting - look here for more information: http://msdn.microsoft.com/en-us/library/ms228302.aspx.  It is pretty much the same as you calling HttpContext.RewritePath.

    Thanks,

    Friday, October 6, 2006 5:54 AM