URL Redirect based on a list in SharePoint 2010 and 2013

Consider the following scenario:
You have an existing website on a platform other than SharePoint, which you are going to migrate. There are thousands of existing links on other websites that you want to remain functional, however in the new SharePoint based website, these pages are stored in different places. You want a central place where users can manage the old links, and tell the users where they have to be redirected to. You would also like to implement ‘Friendly URLs ‘ where the user can type in http://www.somelink.com/friendlyURL and be redirected to http://www.somelink.com/en-EN/subsiteX/subsiteXX/notsofriendlyURL.aspx . These friendly URLs also have to be managed by the website administrator, without having to touch the underlying infrastructure (and specifically IIS).

The solution:
To implement this functionality you can combine a few different SharePoint features with some clever ASP.NET mechanics. Specifically you will need these components:

• A SharePoint List which contains a field for the ‘Old URL’ and a field that specified the ‘New URL’;
• A HttpModule that handles page requests
• A SharePoint Feature to deploy the list, as well as a feature to add the HttpModule to the web.config settings

So let’s get to it and see how we can implement this functionality! (A link to the demo solution is included at the bottom)

Note: This solution assumes that the base URL of the old and new website remains the same. If you are trying to redirect from http://www.websitea.com to http://www.websiteb.com , you will need an additional redirect in IIS that handles the base redirect to websiteb. For this solution to work, the request has to actually be handled by SharePoint.

Note 2: This solution and the demo project is based on SharePoint 2013, although the principle will work for SharePoint 2010 as well.

Step 1
Let’s start by creating our SharePoint Solution. Create an empty SharePoint 2013 project, and add two features to it: one Site scoped feature which we will use to deploy our list, and one Web Application scoped feature which we will use to deploy our web.config modifications.

Step 2
To deploy our list we can choose between the ever-lasting discussion: XML v.s. Code . Personally I am a big fan of creating Lists through code. Right click the Lists feature and click ‘Add Event Receiver’. Uncomment the ‘FeatureActivated’ code and include the following code snippit to create the list: The above code will create a list named ‘URLRedirect’ which contains three fields:

• OldUrl: text field used for storing the old URL which we want to redirect
• NewUrl: Text field used for storing the new URL that we want users to be redirected to
• IsPermanent: Boolean field which is used in our solution to determine if we want to use a 301 redirect (in case of site migration, a 301 redirect is more search engine friendly and overall a better way to redirect), or a normal redirect (in case of a Friendly URL)

Step 3:
In our project, we create business entity classes that represent the list items. Doing this allows you to separate your business logic from the WebParts / Modules which makes it easier to re-use this functionality. Right click the project and add a new Class, I’ve named mine URLRedirectBE. You can find the entire class in the downloadable project, but the important bit here is:If you just want to get the example working, you could also simply create a method that retrieves the ‘NewUrl’ value based on the ‘OldUrl’ value, which is what the method above does for you.  

Step 4:
Now that we have the List and the connection to the List set up, we need to create our HttpModule which actually handles the users’ requests and redirects them if they hit a page that does not exist. To do this, simply add another class to the project and let it inherit from IHttpModule. For this to function you need to include a reference to ‘System.Web’ in your project. The class you would need is included in the demo project, but the important bit is shown below:In the above code we check for a 404 error code, which is the error if a page cannot be found. Another requirement for us was to only perform this check for three types of files: .html, .htm and .aspx. That is why there is an extra check in there. Checking for a 404 error code means that the URL Redirect will only work if the request is not made to a valid page to begin with. If you do want to always check for the list, all you have to do is omit the error code check. This also means that we can only check the URL Redirect list after most of the request has already been server. Although it is a bit slower, this is the earliest point in which we can make the distinction between a 404 and an existing page.

Step 5:
The final step is to create the web.config modification that registers our custom http module in the SharePoint web.config. To do this, right click the Web Application feature and click ‘Add event receiver’. Include the code below to the FeatureActivated method:And for the sake of completeness, include the following code in the FeatureDeactivating method:Simply deploy everything, activate the features and enjoy!

You can download the entire demo solution here.

If you have any comments, please do not hesitate to leave a reply and I will try to get back to you ASAP.

Sources used for writing this blog post are included below:
Waldek Mastykarz – http://blog.mastykarz.nl/sharepoint-2007-redirect-solved-using-301-instead-of-302-redirects/

Gustavo Velez – http://www.developer.com/net/asp/article.php/10917_3812301_2/Extend-the-Flexibility-and-Functionality-of-SharePoint-with-HTTP-Modules-and-Handlers.htm