Let's assume that you have a medium sized SharePoint Server 2007 farm with two WFEs behind an F5 “BIG IP” LTM.
The host name for each configured web application resolves to the Virtual IP (VIP) on the F5, which in turn performs it's sophisticated load balancing function and routes the traffic to one of the two designated WFEs for processing.
Naturally, you would visited F5's web site and followed this deployment guide when creating your configuration profile and HTTP pool. And would assume that all is well, right? Well, mostly, but maybe not...
During testing, you begin to notice that some requests are getting dumped on the HTTP response, which is causing the browser to provide a 404 error. After some investigation, you realize that this abnormality only occurs under very specific, yet obscure, conditions. In my case, I had a custom SharePoint feature which included a WebContol which was loading as a CustomAction in the document library list ViewToolbar. This WebControl performed some configuration settings adjustments similar to those described in my post entitled “Using a Delegate Control Feature to Reconfigure OOTB Site Definitions“. Upon completing the execution of the changes included in my class, I tagged the list to avoid future re-execution of that passage, and performed a page redirect to reload the page so the user would see the new settings.
This is where things got very interesting...
It turns out that I only had the browser 404 when the request traffic was flowing through the F5 LTM. If I set a local host entry on the client, my WebControl would do it's work, reload the page, and everything was just fine. Even more perplexing was the fact that with the custom feature de-activated, initial list library loads flowing through the F5 occurred without error as well. Very strange indeed...
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!).
On a side note, I think it is worth mentioning that if you are doing development of custom components for your SharePoint implementation, and you plan on using an F5 LTM, you might want to avoid performing redirects, especially in cases where you are simply trying to reload the current page for the user. Although, hopefully you find this post first, and simply adjust the settings to resolve the issue entirely.
-Mark
Please feel free to send any thoughts, comments, or questions to mark@solutionsmark.com