What is URL Rewriting?
URL Rewriting refers to the process where your website receives a URL, and is arbitrarily able to redirect it to some other page ~ without the user knowing. The advantage this gives you, is that you can create friendly looking "pretty" URLs, have one single ASPX masquerade as many, and in general give you a much more flexible architecture.
How to do it in ASP.NET?
The simplest way to do this in ASP.NET is to write an HttpModule that takes this responsibility. For instance, in my upcoming webpart based framework, which I am going to call "SpareJoint", which also powers my website - www.winsmarts.com , uses URL Rewriting via an HTTP Module. SpareJoint which will be offered as open source is intended to be a solution that leverages the ASP.NET 2.0 WebPart framework, and allows you to easily setup and create interactive websites with pretty much any look & feel. Purty neat huh? Now pray to god that I get enough time to finish it up and offer it as open source in the next couple of months :).
Implementing a URL Rewriter module is simply a matter of
a) Create a class that implements IHttpModule
b) In the "Init" of that class, subscribe to the event handler as shown below -
public void Init(HttpApplication context)
context.BeginRequest +=new EventHandler(context_BeginRequest);
In the "context_BeginRequest" method, do your actual URL Rewritin'. In SpareJoint, I read from the database, and map the current request to a new URL as specified in the Database. This is damn easy as shown in the code below.
void context_BeginRequest(object sender, EventArgs e)
// Run some custom logic, in my case find urlToChangeTo from DB
d) Now if you run your application, you will note that your site starts URL rewriting. Now it is easy to jump with joy at this time and move on - but that would be a mistake. Don't forget step #e.protected void Page_PreInit(object sender, EventArgs e)
e) In the target ASPX, you need to do the reverse URL rewritin'. Why? why? Because if you don't, and "fakypage.aspx" requested, which is actually being served by "realpage.aspx", all postbacks will go to "realpage.aspx" - and thus completely confuse your application logic. not only that If you had a master page which used a ~/images and ~/styles, and "realpage.aspx" lived at "parentdirectory/realpage.aspx", all relative links will be screwed up :-/. So you need to add the following to the PreInit stage in your "mapped to" aspx (in this case realpage.aspx).
Context.RewritePath(VirtualPathUtility.GetDirectory(Request.RawUrl) + VirtualPathUtility.GetFileName(Request.RawUrl));
Wait a minute, "PreInit"? WHY WHY? What's wrong with "Init"?
Well - the providers are called in a weird sequence. First Modules are called, (so URL Rewriting happens), then your page's PreInit is called, and then the PersonalizationProvider etc. etc., and then your page's Init. So if the reverse URL Rewriting didn't happen before the PersonalizatonProvider was called, it's LoadPersonalizationBlobs methods would get the incorrect path. YUK !!
So if the user added a WebPart to "fakepage.aspx", the personalization store will store it in "fakepage.aspx", but on subsequent requests, it will attempt to read data for "realpage.aspx" - which as you guessed it right, DOESN'T EXIST (because it was never saved).
If this sounds confusing - don't bother understanding :), just put your reverse rewritin' in PreInit - life will be happier that way.
THATS IT !! Now add it to your Web.config as shown below -
BINGO !! You're ready all set to go !! w00t!! :)