ASP.NET & IIS: Domain/URL redirection best practice
In web application, many times we are redirecting domain to other (sub)domain or one url to another url within same domain. So here in this post we will discuss what are the best practices for domain redirection with respect to ASP.NET & IIS and what is the performance impact of it.
What are the scenarios for domain/url redirection?
Following two is the most common scenario for domain/url redirection.
- To enforce primary or canonical domain many time we want to redirect all request to either domain.com or www.domain.com i.e. with www or without www. Indeed this is also required for better SEO rank. You can read my post on same here.
- Change in URL sometime due to change in web url, we are redirecting one url (pattern) to another url (pattern).
What are the solutions?
Often many developers are handling this redirection at ASP.NET level i.e. through code with the help of Response.Redirect, Response.RedirectPermanent, RedirectToAction, RedirectToRoute, etc.
As above all solutions are implemented through ASP.NET hence it initializes ASP.NET request processing and then after it redirect.
Is there any other BETTER solution?
As we know that web server (i.e. IIS in our case) receive request and then after IIS authenticate and identify requested resource type and accordingly it forward request to respective handler (ASP.NET, PHP, CGI, etc) to process it. So here is the scope that rather than handling it at ASP.NET level through code, we can also handle this redirection at IIS level far before forwarding request to respective handler. We can use URL Rewrite extension with IIS to implement domain/url redirection. URL Rewrite module is native IIS module and it plug into the request processing pipeline.
What is the BEST solution and how it could help to gain performance?
We have seen that we can handle such redirection at IIS level and code level through ASP.NET. So now it’s time to evaluate which one is best and how it could help us to gain little performance (yeah every micro-second counts when it come to performance). Have a look at below picture which shows IIS request processing life cycle and it also show where URL Rewrite module & other handlers fit in IIS request processing pipeline.
As we can see in above image that URL Rewrite module plugs far early (A in image) into IIS request processing pipeline than other scripting handler (B in image). Based on above image we can conclude as following.
- If we implement redirection through code i.e. ASP.NET then it will redirect almost at the end of IIS request processing cycle hence new redirected request processing are delayed for time taken by Begin Request to Execute Handler (A to B in above image).
- And if we implement redirection with URL Rewrite module then it redirect in far early stage of IIS request processing cycle and hence new redirected request processing also starts in early stage.
So conclusion is that if we use URL Rewrite module than request are redirected in far early stage of request processing lifecycle and hence it could helps to gain better performance comparatively.
Hope this would be helpful! You can read other post on performance improvements here