背景
我有四台 Windows 服务器,运行 Server 2012 R2,每台都运行 Apache 2.4。这些服务器被安排成两对负载平衡的 Web 服务器,第一对面向互联网,第二对在 LAN 内。有一个传入防火墙规则,允许从第一台服务器到第二台服务器的端口 80 流量进行 API 请求。
我也在局域网中运行 Tableau Server 可视化软件,我当前的任务是通过两组 Web 服务器代理流量到 Tableau。我在外部 Web 服务器上使用以下规则:
/tableau-proxy/* : proxy to the inner web server
/* : run a web app that carries Tableau content
在内部 Web 服务器上,我使用以下规则:
/tableau-proxy/* : proxy to Tableau and strip off the /tableau-proxy prefix
/* : run an API app
对于这两组规则,我使用的是mod_proxy
、mod_proxy_http
和mod_rewrite
。代理本身正在工作;例如,图像请求可以从互联网一路传输,从两个 Web 服务器反弹,到达 Tableau,然后作为 PNG 数据传回给用户。
内容重写问题
这个问题的最后 5% 是重写从 Tableau 返回的 HTML 链接,以便恢复代理子目录前缀。这是在 LAN 端/内部 Web 服务器上。我使用的规则如下:
/ -> /tableau-proxy
我正在尝试使用mod_proxy_html
它,但是使用我使用的配置,我得到的是空白页。有趣的是,它提供的响应代码是 200,因此调试起来有点困难。
配置
我使用的配置是这样的:
LoadModule proxy_html_module modules/mod_proxy_html.so
LoadModule xml2enc_module modules/mod_xml2enc.so
Include conf/extra/proxy-html.conf
<Directory "C:\Apache24\htdocs\public\tableau-proxy">
LogLevel alert rewrite:trace2 proxy_html:trace2
# Proxy requests to the Tableau LB
RewriteEngine on
# Here is a test Tableau server
RewriteRule (.*) http://tabtest/$1 [P]
# Don't make the x-forwarded-for header a list of proxy hops!
# That will break redirects in Tableau
ProxyAddHeaders Off
ProxyHTMLExtended Off
xml2EncDefault utf-8
LogLevel debug
ProxyHTMLEnable On
ProxyHTMLURLMap / /tableau-proxy
</Directory>
当文档沿代理路径返回时,我也尝试保留它的字符集:
ProxyHTMLCharsetOut *
这似乎没有什么区别,结果是:
信息:从 HTTP 标头获取字符集 utf-8
错误:参数无效:[客户端:IP] AH01427:xml2enc:不支持字符集 utf-8
(什么,它不支持UTF-8?)
我尝试过使用不同的 HTML 文档类型,但同样没有任何变化:
ProxyHTMLDoctype XHTML Legacy
我尝试添加代理 HTML 模块作为过滤器,以防万一这样做ProxyHTMLEnable On
,但仍然无济于事:
SetOutputFilter proxy-html
我在网上看到一些其他人遇到此问题的零星报告,上面的一些额外项目代表我尝试了一些建议的解决方案,但空白页仍然存在。我接下来可以尝试什么?
答案1
我找到了一个解决方案。Tableau 包使用 Apache 来提供内容,因此它能够从检测客户端可以接受的编码格式中受益。一位同事建议,也许 HTML 链接重写会阻塞压缩内容,事实证明这是正确的。
因此我习惯mod_headers
关闭压缩,如下:
RequestHeader set Accept-Encoding identity
我的感觉是这不是 Tableau 的问题;我认为问题出在 Apache 代理上,它阻塞了压缩内容。我在网络上的其他地方看到有些人正在将解压缩-修改-重新压缩过滤器添加到他们的代理配置中,大概是为了处理这个确切的问题,但这对我来说不起作用(诚然,我没有坚持这条线索很长时间)。
所以,这是一个解决方法,虽然对我们来说非常可接受。我可能会尝试重新审视这个问题,让压缩再次正常工作。