SharePoint sites and IIS 7 URL rewrite module

Recently while i was working on a public facing SharePoint 2007 website i noticed that whenever a page is requested, SharePoint 2007 uses a 302 (temporary redirect) to redirect users to the page loaceted in site collection. For example when a page with url http://www.mysite.com is requested SharePoint redirects this request to http://www.mysite.com.au/Pages/default.aspx with a status code(302). This works fine for a user requesting this page but this type of redirects is not recommended by most search engines and it could effect the overall search engine ranking for the website. After spending few days trying to find a solution to this problem, one day i came across a very useful article article on Waldek Mastykarz's blog . Although it give me a good starting point but i could not get the suggested solution to work smoothly on my site. Soon after IIS 7 launched their rewrite module, Waldek Mastykarz posted another very useful article on how to implement IIS 7 rewrite module on SharePoint 2007 website, this completely resolves the 302 temporary redirect issue and also explains how to use IIS 7 rewrite module to create a short (seo friendly) page url for SharePoint Website. I am not posting the information that is already provided on Waldek Mastykarz's blog so, if you need more information on using IIS 7 rewrite module on your sharepoint site, please refer to Waldek Mastykarz's blog On this post i will be addressing some common issues that occur after implementing IIS 7 rewrite module on SharePoint 2007 site. 1. 404 page cannot be foound errors while accessing pages thru Sharepoint WCM (web content management) and Sharepoint Designer after implementing IIS 7 rewrite module. 2. Form postback errors after implementing IIS 7 rewrite module. After Implementing IIS 7 rewrite module you will notice that although the site works fine for annonymus users, when you try to access the site through WCM or Sharepoint designer for authoring you recieve a 404 page not found message. This happens because IIS can not distinguish between an edit page request and a normal view page request so it returns a rewritten url in both cases and obviously the WCM or Sharepoint designer cannot find the page. So, after all that effort :) how do we get this to work for both website visitors and content authors? its quite simple, you just need to extend your SharePoint Web application. Give your extended application a name that can be easily distinguished from the original application for example if you original application was called [SITE] name the extended application something like [staging.SITE]. now you should see two seperate site under IIS a. SITE (this will be used for the public website and will use iis 7 rewrite module) b. staging.SITE (this will be used by the content authors and will NOT use iis 7 rewrite module) More information on how to extend an existing web application can be found under http://technet.microsoft.com/en-us/library/cc262668.aspx After you have extended your Sharepoint Web application. Log on to Sharepoint Central Admin, click on Operations >> Alternate access mapping >> Edit public zone url's >> from the Alternat access mapping collection drop down list, select your web application (SITE) >> under default add your public site url >> under Internet >> add your authoring url >> save. By using this method there is no conflicts between the rewrite module and page edit requests. Resolving Form Postback : Asp.Net web Forms use form postback to maintain the state of server side controls. When a server side control is added on web page, Asp.Net will render form tag that contains an action attriribute pointing back to the page where the form control is. This means that if rewriting was used for that page, the action attribute will point back to the rewritten url, not the url that was requested from the browser. This will cause the browser to show rewritten url any time postback occurs There are a few workarounds to fix this problem. For example, you could sub-class the form control, or use Control Adapter. However, these workarounds were not very easy to implement. Luckily, .NET Framework 3.5 SP1 provides a very simple way to fix this issue. You can use the property of HtmlForm class called Action to set the postback URL to the one that was requested by browser before any rewriting happened. You can obtain that URL from a server variable set by URL rewriting component. For example ISAPI_Rewrite saves it in a server variable called HTTP_X_REWRITE_URL. URL Rewrite Module for IIS 7.0 saves it in HTTP_X_ORIGINAL_URL. So, to fix the postback URL for your web form when you use URL Rewrite Module, you would need to add the following code to the page: protected void Page_Load(object sender, EventArgs e) { if ( !String.IsNullOrEmpty(Request.ServerVariables["HTTP_X_ORIGINAL_URL"]) ) { form1.Action = Request.ServerVariables["HTTP_X_ORIGINAL_URL"]; } } finally, if you are using this function directly on your master page, do not forget to edit your web.config file between <PageParserPaths> tags add < PageParserPath VirtualPath="~/_catalogs/masterpage/YourMasterPage.master" CompilationMode="Always" AllowServerSideScript="true" > to allow script execution.