目前，我们公司正在支持一个使用内置Web服务器（由名为Web Server 4D的扩展提供）在第四维（2003）中编写的（非常古老的）启用Web的数据库应用程序。 由于Web服务器没有SSL支持，我们的客户端设置Apache来处理外部HTTPS连接（通过<VirtualHost> ），并使用mod_proxy通过HTTP将所有stream量路由到WS4D服务器。 路由工作正常。
问题在于WS4D服务器在构build页面时经常打印出破损的URL。 由于WS4D服务器不知道Apache，只要打印出一个完整的URL（包含域），就会在URL中打印出一个内部域名和端口号，而不是外部URL（例如http：// localhost：9999 /在家而不是https://www.example.com/home ）。 大多数其他链接是相对的（如/img/smiley.png），因此工作正常。
为了解决这个问题，我们尝试设置一个名为mod_proxy_html的第三方Apache模块，用正确的域重写链接。 然而，只要我们在httpd.conf中激活模块（ ProxyHTMLEnable On ，但没有定义重写规则），突然之间，我们的PNG和AJAX请求（之前工作的）都无法加载！ 我不确定，但我认为服务器可能会返回这些与错误的MIMEtypes。
有谁知道我们如何解决/debugging这个问题？
更新：我检查了PNG的链接，因为它们是相对链接（例如/img/smiley.png），所以它们正在打印出来。 然而，当我把URL放到浏览器中的时候，我得到了一堆乱码（我认为这是一个格式化为文本的二进制图像）。 奇怪的是，最开始有三个HTML标签： <html><body><p> 。
更新2：标记绝对不是由我的浏览器（Safari）添加。 当我closuresmod_proxy_html ，图像正常载入页面，但直接访问URL时仍然以文本方式打开。 closuresmod_proxy_html后，图像源中的<html><body><p>标记消失。
这是一个MIMEtypes的问题。 WS4D服务器使用Content-Type为text/html而不是image/png将所有PNG传输到Apache，这导致mod_proxy_html将它们解释为HTML文件并parsing它们。 显然， mod_proxy_html自动尝试通过在文件的开头添加任何缺less的标记来符合HTML规范（可能是使用libxml2的副作用）来自动尝试修正不正确的HTML。 无论何时我们启用了模块，它都会将<html><body><p>到所有PNG文件的开头，导致浏览器窒息而不显示它们。 纠正MIMEtypes完全解决了这个问题。
我们从来没有发现为什么我们的AJAX失败，因为只要我们修复PNG，它就开始工作了。 我们的AJAX代码通常通过Apache从WS4D服务器加载HTML代码片段。 在我们修复我们的PNG之前，它显示了一个错误消息，通常只有当一个AJAX请求返回一个错误代码时才会显示。 我们的理论是HTML片断中的PNG破坏会以某种方式产生错误，但我们无法validation这一点。
外卖：如果你打算使用mod_proxy_html ，仔细检查你的MIMEtypes！