We are trying to get an F5 BIG-IP LTM iRule working properly with SharePoint 2007 in an SSL termination role. This architecture offloads all of the SSL processing to the F5 and the F5 forwards interactive requests/responses to the SharePoint front end servers via HTTP only (over a secure network).
For the purposes of this discussion, iRules are parsed by a Tcl interpretation engine on the F5 Networks BIG-IP device.
As such, the F5 does two things to traffic passing through it:
- Redirects any request to port 80 (HTTP) to port 443 (HTTPS) through HTTP 302 redirects and URL rewriting.
- Rewrites any response to the browser to selectively rewrite URLs embedded within the HTML so that they go to port 443 (HTTPS). This prevents the 302 redirects from breaking DHTML generated by SharePoint.
We've got part 1 working fine.
The main problem with part 2 is that in the response rewrite because of XML namespaces and other similar issues, not ALL matches for "http:" can be changed to "https:". Some have to remain "http:". Additionally, some of the "http:" URLs are difficult in that they live in SharePoint-generated JavaScript and their slashes (i.e. "/") are actually represented in the HTML by the UNICODE 6-character string, "\u002f".
For example, in the case of these tricky ones, the literal string in the outgoing HTML is:
http:\u002f\u002fservername.company.com\u002f
And should be changed to:
https:\u002f\u002fservername.company.com\u002f
Currently we can't even figure out how to get a match in a search/replace expression on these UNICODE sequence string literals. It seems that no matter how we slice it, the Tcl interpreter is interpreting the "\u002f" string into the "/" translation before it does anything else.
We've tried various combinations of Tcl escaping methods we know about (mainly double-quotes and using an extra "\" to escape the "\" in the UNICODE string) but are looking for more methods, preferably ones that work.
Does anyone have any ideas or any pointers to where we can effectively self-educate about this?
Thanks very much in advance.
What you are trying to do is not recommended with SharePoint.
The recommended approach is to use Alternate Access Maps inside of SharePoint. You will create a public URL of https:// and have an internal name of http://.
This will cause all URLs on your page to be created using https://
You may want to ask this on ServerFault http://serverfault.com if you do not like the answer.
@JD, I probably should have added this:
The SharePoint Web Application in question is currently hosted on a physical server and SharePoint Farm that is integrated (on other Web Applications) with SQL Server 2005 Reporting Services (SSRS) and PerformancePoint 2007 (PPS). Both products DO NOT support Alternate Access Mappings (AAM).
While it's true that the Web Application we want to do the above with is not integrated with SSRS or PPS, our architect and our technical leads would prefer to avoid using AAM at all in that environment if at all possible.
So while in principle, I agree with your answer, in this case, I am asking for special exception and am asking about Tcl and UNICODE escaping in particular because I and our other technical strategists believe that this is the right answer in this particular situation.
I know nothing about sharepoint, but at least from a pure tcl perspective, the following shows how to match your literal string:
The important thing is to make sure that the backslash in \u002f isn't interpreted by the tcl parser (by enclosing the pattern in {}) and to also make sure the backslash isn't interpreted by the regular expression parser (by escaping it with a backslash).
For future reference since this has come up recently as well...
Sharepoint Alternate Access Mappings is the cleanest solution.
For a BIG-IP iRule you can try something like this. Note that TCL needs to interpret the unicode characters before it can match them.
Aaron
replace \123\abc with \456\def
STREAM::expression {@\\123@\456@ @\\abc@\def@}