我们正在尝试让 F5 BIG-IP LTM iRule 在 SSL 终止角色中与 SharePoint 2007 正常工作。此架构将所有 SSL 处理卸载到 F5，F5 仅通过 HTTP（通过安全网络）将交互式请求/响应转发到 SharePoint 前端服务器。
为了本次讨论的目的，iRules 由 F5 Networks BIG-IP 设备上的 Tcl 解释引擎进行解析。
因此，F5 对通过它的流量做两件事：
- 通过 HTTP 302 重定向和 URL 重写将对端口 80（HTTP）的任何请求重定向到端口 443（HTTPS）。
- 重写对浏览器的任何响应，以选择性地重写 HTML 中嵌入的 URL，使其转到端口 443 (HTTPS)。这可防止 302 重定向破坏 SharePoint 生成的 DHTML。
第一部分已经运行正常。
第 2 部分的主要问题是，由于 XML 命名空间和其他类似问题，在响应重写中，并非所有“http:”匹配项都可以更改为“https:”。有些必须保留“http:”。此外，一些“http:”URL 很难处理，因为它们位于 SharePoint 生成的 JavaScript 中，并且它们的斜线（即“/”）实际上在 HTML 中由 UNICODE 6 个字符的字符串“\u002f”表示。
例如，在这些棘手的情况下，传出的 HTML 中的文字字符串是：
http:\u002f\u002fservername.company.com\u002f
应改为：
https:\u002f\u002fservername.company.com\u002f
目前我们甚至无法弄清楚如何在这些 UNICODE 序列字符串文字的搜索/替换表达式中获得匹配。似乎无论我们如何对其进行切片，Tcl 解释器都会先将“\u002f”字符串解释为“/”转换，然后再执行其他任何操作。
我们已经尝试了我们所知的 Tcl 转义方法的各种组合（主要是双引号和使用额外的“\”来转义 UNICODE 字符串中的“\”），但正在寻找更多方法，最好是可行的方法。
有谁能给我们一些想法或指点，让我们可以有效地进行自我教育？
首先十分感谢。
答案1
SharePoint 不建议您尝试执行此操作。
推荐的方法是使用 SharePoint 内部的备用访问映射。您将创建一个公共 URL https:// 并拥有一个内部名称 http://。
这将导致您页面上的所有 URL 都使用 https:// 创建
如果您不喜欢这个答案，您可能想在 ServerFault http://serverfault.com 上提问。
答案2
@JD，我可能应该添加这一点：
有问题的 SharePoint Web 应用程序目前托管在物理服务器和 SharePoint Farm 上，该服务器和 SharePoint Farm 与 SQL Server 2005 Reporting Services (SSRS) 和 PerformancePoint 2007 (PPS) 集成（在其他 Web 应用程序上）。这两种产品都不支持备用访问映射 (AAM)。
虽然我们要用来执行上述操作的 Web 应用程序确实未与 SSRS 或 PPS 集成，但我们的架构师和技术主管还是希望尽可能避免在该环境中使用 AAM。
因此，虽然原则上我同意您的答案，但在这种情况下，我要求特殊例外，并特别询问有关 Tcl 和 UNICODE 转义的问题，因为我和我们的其他技术策略师认为这是在这种特定情况下的正确答案。
答案3
我对 sharepoint 一无所知，但至少从纯 tcl 角度来看，以下内容显示了如何匹配文字字符串：
tclsh> set string {http:\u002f\u002fservername.company.com\u002f}
http:\u002f\u002fservername.company.com\u002f
tclsh> regexp {http:\\u002f} $string
1
重要的是确保 \u002f 中的反斜杠不被 tcl 解析器解释（通过将模式括在 {} 中），并且还要确保反斜杠不被正则表达式解析器解释（通过使用反斜杠进行转义）。
答案4
将 \123\abc 替换为 \456\def
流::表达式 {@\\123@\456@ @\\abc@\def@}