Many customers who use SharePoint Server 2010 for their Internet-facing website, ask for a mechanism that would allow them to use short URLs like http://www.awt.com/edinburgh instead of http://www.awt.com/destinationguides/uk/scotland/edinburgh/. SharePoint 2010 doesn’t have such mechanism out of the box and if you know SharePoint at least a little, you know that there is always more than one way to get something done. So what are the possibilities and which one of them is the best to use?

Short URLs are useful for many purposes. They simplify both internal and external communication and allow marketing departments to facilitate campaigns and measure the effects by including some additional information in the URLs. Additionally, if they are understandable by the visitors, short URLs simplify navigating through the website. Those as well as many other reasons makes short URLs a highly desired feature especially among the editors of dynamic websites.

Since its previous release SharePoint supports creating Internet-facing websites, which is different from creating collaboration solutions or company-wide intranets. Because Internet-facing website are globally available there are more/different things that you have to take into account than in an closed environment such as your intranet. This difference applies to many requirements among which URLs redirection. In spite of the fact that URLs redirection is something that customers frequently ask for, it isn’t available in SharePoint out of the box. So what can you do when asked about URLs redirection in SharePoint? Let’s have a look at a few common approaches you might have heard of.

Link Conductor

Link Conductor is a Sandboxed Solution created by zevenseas. It allows you to easily create and manage short URLs using a SharePoint List. The short URLs that it creates are like: http://www.awt.com/go.aspx?guides=edinburgh.

The great thing about this solution is that it’s a Sandboxed Solution created specially for SharePoint 2010. Because of that it can be installed and managed by Site Collection Administrators without the involvement of the IT. Additionally it allows you to count the visits to each short link what can be useful in analyzing the traffic on your website. As all short URLs are stored in a SharePoint List, deploying Link Conductor in a multi Web Front End (WFE) Farm is not a problem: as long as they all share the same content database, they can use the same redirects without a problem.

The downside of using Link Conductor is the fact that it doesn’t allow you to configure the HTTP codes for the redirect, making each redirect a temporary redirect what’s quite bad in terms of Search Engines Optimization: in most scenario’s search engines don’t follow temporary redirects, so widely using such short links might limit the indexing of your website. Additionally Link Conductor uses query string parameters which adds complexity and decreases the readability of short URLs.

Link Conductor is a great solution if you’re looking for a short URLs solution for your intranet. Unfortunately the flexibility and ease of use pays the price for making it a solution that you could successfully use on your Internet-facing website.

SharePoint GoCodes

SharePoint GoCodes is a solution for using short URLs with SharePoint that I created a while ago. While originally developed for SharePoint 2007, it should work with SharePoint 2010 as well. The SharePoint GoCodes solution is similar to Link Conductor: it also uses a SharePoint List for managing redirections and it also allows you to count the number of times a short URL was used.

SharePoint GoCodes has been created considering the usage on Internet-facing websites. It uses permanent redirects (301 HTTP code) what tells search engines to follow the redirect while crawling the content and the short URL is slightly more user friendly: http://www.awt.com/go/edinburg. No query strings here.

While SharePoint GoCodes takes you a step closer to a solution that you could successfully use on your Internet-facing website, it isn’t perfect. The URLs it uses are not perfect – you have to use the go part, which you could rename to something else but you cannot remove it. Additionally it is a Farm Solution which uses a custom HTTP Handler. This makes it slightly more complex to deploy and cannot be done without the help of the IT department. The more optimal redirects of SharePoint GoCodes come with the price of flexibility and ease of deployment.

URL Rewrite 2.0

URL Rewrite 2.0 is a URLs management component for IIS7. Although it’s called URL Rewrite it allows you to create and manage both URL rewrites and redirects.

Probably the best thing about the URL Rewrite 2.0 is that it’s a solution provided and supported by Microsoft that fully integrates with IIS7. Because it doesn’t involve installing custom code, it lowers the barrier of installing it.

As mentioned before, URL Rewrite 2.0 allows you to do both rewriting and redirecting URLs. One important thing to note, is that rewriting URLs in SharePoint is not supported, and if you choose to do it, you will be doing it at your own risk. You are allowed to use URL Rewrite 2.0 for URL redirects though.

For creating multiple redirects, URL Rewrite 2.0 allows you to define rewrite maps which are basically groups of redirects. Then you can assign a rewrite map to a redirect rule what makes it a matter of minutes to configure short URLs with URL Rewrite 2.0. The ease of configuration combined with the fact that there are virtually no restrictions for creating the short URLs (yes, you can create a short URL like http://www.awt.com/edinburgh with URL Rewrite 2.0) make URL Rewrite 2.0 look like a perfect candidate for creating short URLs with SharePoint. There are two more things you should consider before you turn the switch on.

URL Rewrite 2.0 is an IIS7 solution. This means that it hasn’t been created specifically for SharePoint and therefore it doesn’t integrate with it. So far the only way of managing the rewrite maps is from the IIS Manager interface what makes it impossible for business to use by themselves. In order to create a new redirect they will have to call the IIS admin and there is no way around it at this moment.

The second thing that you have to consider is when using URL Rewrite 2.0 in a multi-WFE environment. Rewriting/Redirecting URLs using URL Rewrite 2.0 is enabled on IIS on a specific server, on a specific Web Application. Additionally all rewrite maps are defined within that single Web Application and are stored in its web.config. So in order to successfully use URL Rewrite 2.0 with SharePoint 2010 on a multi-WFE farm you would have to find a way to keep the rewrite maps of all WFE’s in sync what can quickly get really complex, especially if someone decides to start using SPWebConfigModifications.

Although URL Rewrite 2.0 seems like a perfect candidate at first glance, it has some serious limitations, especially if considered to be used with larger deployments. Lack of interface for users other than IIS admins, no integration with SharePoint and no support for multi-WFE farms are serious drawbacks to consider before starting using it with SharePoint 2010.

Custom solution

If the platform doesn’t support what you want, you have two options: you can either adjust your requirements or create something yourself. While it’s never too late to drop some requirements, let’s have a look at how things look like if we decided to create a short URLs solution for SharePoint ourselves.

First things first: the requirements

Looking at our scenario the perfect solution should have the following capabilities:

• allow administration of short URLs on the Site Collection level
• support easy to read URLs
• use permanent redirects to play nicely with search engines on the Internet
• support multi-WFE environments
• don’t have a serious performance penalty

There are more requirements that we could think off but the above is probably the absolute minimum you would like to start with.

The first and probably the most important thing from the business perspective is the ability to mange the short URLs by themselves. Depending on your scenario this might be a quite important requirements. Many websites driven by marketing departments require great flexibility and calling the IT each time they need a new redirect is the very opposite of what they have in mind.

Supporting easy to read URLs means nothing more than avoiding using complex URLs with query strings and such. A URL like http://www.awt.com/edinburgh would be perfect but the business might agree on http://www.awt.com/guides/edinburgh as well.

As mentioned before using temporary redirects for short URLs can lead to indexing issues with search engines on the Internet which in most scenarios don’t follow temporary redirects. Using permanent redirects is a better practice and definitely something that our solution should take into account.

In most scenarios SharePoint Server 2010 is being used as a platform for Web Content Management solution for somewhat larger sites. In such scenarios using multiple Web Front Ends is a common practice: either if it’s for load balancing, high availability or a combination of both. A perfect solution for short URLs should support being deployed on multiple WFEs without too much effort.

Implementing a URL redirect solution means intercepting all incoming requests. After all you cannot be sure if the requested URL shouldn’t be redirected if you haven’t checked it first. A good URLs redirecting solution should do the check as quickly as possible without too much impact on the performance of the website.

Now we have more understanding of what a custom URLs redirecting solution should be able to do and why, let’s have a look at the possibilities that SharePoint has to offer.

Creating a custom URLs redirecting solution: technical design

Probably the only candidate that supports all of the above requirements is a custom HTTP Module: it’s the only way you can intercept an incoming request in SharePoint/ASP.NET, allowing you to use easy to read URLs. While it’s not that difficult to create a custom HTTP Module there are a few things that you should understand why it’s not necessarily a better approach than the one we discussed before.

First and the most important of all: using custom HTTP Modules with SharePoint is not supported recommended. The reason for this is that the request/response pipeline of SharePoint is already complex by its own and adding anything else to it can make things go really bad. With that said you have two options: either stick with a custom HTTP Module knowing that you are unsupported what you are doing or go talk with the business and try to convince them why it’s a bad idea.

Assuming you are able to convince the business to agree on using some kind of prefix you can provide them with a workable solution. In such scenario the first alternative that you can consider is a solution comparable to SharePoint GoCodes. It allows you to use easy to read URL’s, it’s a SharePoint specific solution that allows you to managed the redirects through a standard SharePoint list and it can be deployed on a multi-WFE farm without too much work. Alternatively you might want to go with Link Conductor and ask your admin to configure each IIS server with URL rewriting so that the querystring-based redirects would become more end-user friendly.

If you however won’t manage to convince the business and they keep insisting on having all requirements in place, you will have to be really careful. First of all you have to find a way to process only the right requests. As mentioned before you have to intercept all of them, so eventually your HTTP Module will end up being hit by ASPX pages, JavaScript and CSS files, images and everything else that’s being processed by IIS. To limit the performance penalty you have to think of a way to quickly determine if the requested URL is a candidate for a redirection or not. Another thing that you have to consider is resolving the redirections. While you might want to lookup the list at first it’s far from the best choice. Opening a reference to a Site Collection, a Site and a List each time you need to do a redirect is painfully slow. Oh, and before you start storing the redirect URL’s in the cache take multiple WFE’s into account and revalidating the cache on all machine each time something in the list changes. No one told you it would be easy…

Conclusion

SharePoint 2010 is a highly extensible application platform. While it offers some great extensibility capabilities it has its limitations and URLs rewriting and redirection is one of them. Like any other challenge implementing a URLs redirecting solution can be done in many different ways and it’s your responsibility to review different approaches against the requirements to make an educated choice. In some scenarios it might be very easy to fulfill all requirements while in others it might be wiser to drop some requirements in order to deliver a solution that will work better in the long run. To keep it short: Does SharePoint support short URLs? It depends.

Technorati Tags: SharePoint 2010,WCM