So I am setting up a standard 5 server SharePoint 2010 farm (2WFE, 1 App, 2 Clustered DB Servers) for a client. The client is giving me the minimal security permissions for setup and installation, so my troubleshooting options are limited.
I have the farm setup and Central Admin running, so today I created the first web app and site collection. To my dismay, I was unable to open the new site. I received a 504 Gateway timed out error. Ok, I can’t exactly be like hey guys your network won’t let me through (oh yeh I have no access to DNS or the network load balancer). So I start digging trying to figure out what is going on. I pull out my trusty fiddler and lo and behold, when I type in the url of the server, I am getting the normal 302 redirect from www.domain.com/ to www.domain.com/SitePages/default.aspx, but there’s more, It was actually a port redirect too, it was actually redirecting from http://www.domain.com/ to https://www.domain.com/SitePages/default.aspx.
So my first step was to modify the HOSTS file to point directly to each web front end to see if this was SharePoint or the network.
As you can see, bypassing the F5 works. SharePoint is up and running.
So now, what is going on. Well after some digging, I found this post and full credit goes to Mark Ferraz : http://mindsharpblogs.com/markf/archive/2008/03/14/4445.html
The following excerpt is what is happening and how to fix it. Yes, it lies in the F5 and for whatever reason, the F5 provides a ‘feature’ where when it receives a redirect it actually redirects it to HTTPS or port 443 in addition to the actual redirect. Nice feature, right, no not really for SharePoint. So basically changing the Redirect Rewrite in the F5 to none will resolve the issue.
So, a few fine colleagues and I began the lengthy process of sniffing the traffic using Net Mon on both the client and the server in order to find out exactly what was happening. What we found was both slightly confusing, and very unexpected. To set this up, let’s go back to the F5 Deployment guide I referenced earlier. In section 1-8, the guide lays out the steps for creating the HTTP pool. Step 6 states:
6. In the Settings section, check the Custom box for Redirect Rewrite, and from the Redirect Rewrite list, select Matching.Well, it turns out that Redirect Rewrite is an interesting little feature indeed. SOL9612 on the F5 support site (requires registration) describes the specifics of this setting, which is so quickly passed over in the deployment guide it isn’t even funny.
Basically, when a requested URI does not include a trailing slash (a forward slash, such as /, at the end of the URI), some web servers generate a courtesy redirect. That sounds like an OK thing, right? Sure, but guess what, and this is the “Gottcha“…
In BIG-IP LTM version 9.x you can configure an HTTP profile to rewrite URLs so that redirects from an HTTP server specify the HTTPS protocol.
Whoa, what just a minute! That doesn’t even sound like the same feature. how did we go from slashes to protocol redirection. Hmmmm…. As it turns out, the Redirect Rewrite options available are as follows:
- Choose All to rewrite any HTTP 301, 302, 303, 305, or 307 redirects to HTTPS
- Choose Matching to rewrite redirects when the path and query URI components of the request and the redirect are identical (except for the trailing slash)
- Choose Node to rewrite redirects when the redirect URI contains a node IP address instead of a host name, and you want the system to change it to the virtual server address
So, basically, if we follow the settings recommendations included within the deployment guide referenced above, we inadvertently setup the F5 in such a way that any redirect with a matching referrer, such as the one I had placed in my WebControl, will cause the HTTP response coming from the WFE to be rewritten by the F5 as an HTTPS response… as a courtesy, of course 🙂
Ok, back to the deployment guide one more time… Above the step by step in section 1-8, there is a short disclaimer as well as a note written in italics. These state the following:
Important: If you are using the WebAccelerator module, we recommend you configure an HTTP profile based off of the default HTTP profile, and only change the Redirect Rewrite option to Match. Any other settings in this case are optional.-and-
The following procedure shows one way to optimize the Microsoft SharePoint 2007 configuration that has been tested in real-world scenarios by F5, and shown to give the greatest improvement. These procedures and the specific values given in some steps should be used as guidelines, modify them as applicable to your configuration.
So, what the fine print is really saying here is:
- If we are using the WebAccelerator module, we should NOT set the Redirect Rewrite options to Matching, but rather set it to Match, which interestingly enough is not a listed option in the above referenced support article on the F5 support site, nor (as is the case with all the options for this setting) is it listed or explained anywhere in the deployment guide.
- These settings, including step 6, and their specific recommended values should be used (only) as guidelines, and may require modification in your environment.
Well, in the case of a SharePoint implementation, while I can see some value in the whole trailing slash detection thing, I can’t see many cases where I would want HTTP traffic being converted into HTTPS traffic, at least not in this case. Upon changing the Redirect Rewrite setting to None, everything works fine again and the browser errors disappear (magic!).
—Credit to Mark Ferraz