Url Rewriting using IHttpModule vs ISAPI Rewrite

Why not use IHttpHandler for rewriting:

You can find the previous post I've done on this subject here, it has a c# source code example and will also explain some of the downfalls of using the IhttpHandler for rewriting.  In summary my basic feeling on this is IhttpHandler is great if you know the Url that is going to be requested eg. /Rss.ashx every time an rss reader requests this Url, the reader will never know that Rss.ashx doesn't necessarily have to exist as the response is picked up and written back by the handler.

How is IHttpModule more useful url rewriting?

When it comes down to rewriting urls where the requested Url is not known or is dynamically generated IHttpModule makes it easier to manipulate the request as it passes down the asp.net stack.  So creating an ASP.NET url rewriter it's just a simple matter of attaching a httpmodule that can identify the dynamic url and rewrite it before it requests a page that doesn't exist (eg a 404).

The way I chose to do this in pure asp.net was to use regex matching.  Every request that comes in is tried against a regex pattern, if the url makes a match it is rewritten to the handling page (or possibly a IHttpHandler) to return the response.

But nothing beats ISAPI rewrite, right?

I'd say yes and no to this, ISAPI rewrite uses 'almost' the same principle as my module, except it rewrites the Url as it enters IIS and before the request even gets to the ASP.NET request handler.  This means the client will think they are at a particular url eg /rss/ but the request could be transformed by ISAPI rewrite to /feeds/rss.ashx.  One thing ISAPI rewrite can do that the .NET module can not is it is able to hide the page's language extension (eg. .aspx), but doing this is not a huge benefit unless you want to change your site's programming language which would most likely break all your referring links if the extension is present.

The ASP.NET way:

So now for the things that the ASP.NET way does better. Because the rewriting is done at the ASP.NET level, .NET knows about it, this means ASP.NET can auto-magically resolve all those virtual ~/paths correctly.  There are also some other SEO advantages to doing this such as utilizing the keywords in your url as opposed to having a meaningless url full of query parameters which will get you nothing, well it might get some SEO points, but not as much as you could.

The ideal solution for ASP.NET:

I think the ideal way to do rewriting for ASP.NET is use both ISAPI in combination with a .NET module for the reasons listed above.  ISAPI rewrite gives that edge of power over IIS that a class inside ASP.NET can't, so urls can look like directories ('/') rather then .aspx pages, plus the ISAPI rewrite configuration file is very convenient and configurable.  The .NET module comes in handy to rewrite the url from a dynamic location to the real location of the page and is able to resolve all the ~/ virtual directories in the process.

An example of this that I've done using a combination on another site is as follows:

Request comes to: http://www.site.com/second-level/content-title/
ISAPI rewrites to: http://www.site.com/second-level/content-title/ResolvePage.aspx
My .NET module watches for requests to ResolvePage.aspx and does an ASP.NET Context.RewritePath() to the real content page location of http://www.site.com/Content.aspx?path=content-title
This then causes Content.aspx to render 'as if' it was at the requested location eg.
http://www.site.com/second-level/content-title/ResolvePage.aspx so all the virtual paths are correct in the requesting browser.

And there it is a friendly, programming language free, keyword rich url living in harmony with ISAPI and ASP.NET. Search engines are happy, users have nice clean hackable urls to look at and remember and are happy.  Everybody is just happy.

 

Edited using Windows Live Writer, thanks Matt!

General .NET SingleUserBlog
Posted by: Brendan Kowitz
Last revised: 21 Sep 2013 12:15PM

Comments

9/19/2006 11:29:38 AM
Hello,

The solution looks good, indeed solving all issues ... however .. are ISAPI modules accepted by hosting companies in general?

Paul
9/19/2006 12:05:42 PM
In order to have the solution easily accepted by WebHosting companies, could it be a solution to use the 404 error setting on IIS to specify a error-ASPX file?

The request of a non-existing file (or foldernames) is send to asp.net this way ... the HTTPModule can then determine what to do with the user-specified url ....

Or does this scenario create new and greater problems? Any thoughts?

Paul

9/19/2006 7:24:55 PM
Paul, in regards to webhosts; I think finding a host with IIS+ISAPI Rewrite would be harder then finding a linux host with Apache+mod_rewrite, mainly because ISAPI Rewrite is not free.

As with the 404 idea, yes it might work, or the request might miss your ASP.NET application depending on the server’s config. You would need to be very careful and do things like changing the outgoing response headers to 200 or GoogleBot would probably ignore your content.

To me the idea of rewriting urls is to handle it before it reaches a 404. I think of a 404 as being at the very end of a request’s attempts to get content and is a place I'd prefer not to go unless the content is actually missing.

You don't need ISAPI Rewrite if you do your urls the all ASP.NET way (have the .aspx extension), which in most cases should be fine.
10/10/2006 3:40:38 AM
If you write your own ISAPI it is free. As for a hosting company you still would have to have a Colo-LINUX box or a Colo-IIS server unless your hosting environment lets you install ISAPI DLL's on the server in the case of IIS or Install Application on the LINUX box.
12/18/2006 5:10:53 PM
From IIS6 and above you can define wildcard mappings on a per site basis.
That means that any requests where there isn't a corresponding physical file will be redirected to asp.net
At which point you can setup a file with no content in a folder like say /ToRewrite/Default.aspx and have all requests routed there.
In the rewrite module you intercept those requests and voila
no ISAPI module needed and your rewriting works like a charm.
12/18/2006 6:15:44 PM
This is an option, however two reasons why I wouldn't implement it at a commercial level are:
The ASP.NET plugin would then be serving all content when it doesn't need to. IIS serves static content (images etc..) more efficiently without invoking the ASP.NET plugin.
And second, I'm not aware of a shared webhost that wildcard maps all requests into ASP.NET.

I hear that there will be a better solution for .NET and url mapping / rewriting with IIS7 + .NET3 when it comes out.
http://weblogs.asp.net/scottgu/archive/2005/11/14/430493.aspx

But until then I'd still stick with ISAPI Rewrite.
7/11/2007 7:07:31 AM
Brendan,

finally, after a long search this seems to be the solution to my problem.

Im particalarly interested in this part you mention you've done for another site:
Request comes to: http://www.site.com/second-level/content-title/
ISAPI rewrites to: http://www.site.com/second-level/content-title/ResolvePage.aspx
My .NET module watches for requests to ResolvePage.aspx and does an ASP.NET Context.RewritePath() to the real content page location of http://www.site.com/Content.aspx?path=content-title
This then causes Content.aspx to render 'as if' it was at the requested location eg.
http://www.site.com/second-level/content-title/ResolvePage.aspx so all the virtual paths are correct in the requesting browser.

Could you provide me with the sourcecode to perform these steps?
so: isapi_rewrite regex
you logic in the .NET module and your context.rewritepath code.

If you would be so kind to mail the code to me I would be very thankful!

Im I correct that the user at all times will see "http://www.site.com/second-level/content-title/" in his browser addressbar?

Thank ahead! :)
2/12/2009 9:27:50 AM
Hi,

I need to avoid question mark in URL? Can you please help me. It is very urgent plz help me.

Thanks & Regards,
Hemalatha
2/12/2009 11:45:21 AM
@Hemalatha

Have a look at the documentation for "Context.RewritePath()". The idea of this post was to show you how to 'internally' rewrite a request from www.site.com/product/anything.aspx to www.site.com/ResolvePage.aspx?path=anything. The important thing to note with an internal rewrite is the URL does NOT change for the user! They will continue to see the friendly version.
10/28/2009 9:50:50 AM
Nice post,

Some great advice on the benefits of using IHttpModule for Url Rewriting,

Anyway, thanks for the post

No new comments are allowed on this post.