我们公司目前正在支持一个（非常老旧的）基于 Web 的数据库应用程序，该应用程序使用 4th Dimension (2003) 编写，并带有内置 Web 服务器（由名为 Web Server 4D 的扩展提供）。由于 Web 服务器不支持 SSL，因此我们的客户设置了 Apache 来处理外部 HTTPS 连接（通过<VirtualHost>），并使用 将所有流量通过 HTTP 路由到 WS4D 服务器mod_proxy。路由运行正常。
问题是，WS4D 服务器在构建页面时经常会打印出错误的 URL。由于 WS4D 服务器不了解 Apache，因此每当它打印出完整的 URL（包括域名）时，它都会在 URL 中打印出内部域名和端口号，而不是外部域名和端口号（例如http://本地主机:9999/home代替https://www.example.com/home)。大多数其他链接都是相对的（例如 /img/smiley.png），因此可以正常工作。
为了解决这个问题，我们尝试设置第三方 Apache 模块，以mod_proxy_html使用正确的域重写链接。但是，每当我们在 httpd.conf 中激活模块时（使用ProxyHTMLEnable On，但没有定义重写规则），我们的 PNG 和 AJAX 请求（之前可以正常工作）就会突然加载失败！我不确定，但我认为服务器可能返回了错误的 MIME 类型。
有人知道我们如何修复/调试这个问题吗？
更新：我检查了 PNG 的链接，由于它们是相对链接（例如 /img/smiley.png），所以打印出来没问题。但是，当我将 URL 放入浏览器时，我得到的是一堆乱码（我猜是格式化为文本的二进制图像）。而且，奇怪的是，最开始有三个 HTML 标签：<html><body><p>。
更新 2：标签肯定是不是被我的浏览器 (Safari) 添加。当我关闭时mod_proxy_html，图像会正常加载到页面中，但当我直接访问 URL 时仍会以文本形式打开。mod_proxy_html关闭后，<html><body><p>图像源中的标签会消失。
答案1
这是一个 MIME 类型问题。WS4D 服务器将所有 PNG 传输到 Apache 时使用的是 而不是，Content-Type这导致将它们解释为 HTML 文件并进行解析。显然，会自动尝试通过在文件开头添加任何缺失的标签来更正不正确的 HTML，以符合 HTML 规范（可能是使用 的副作用）。每当我们启用该模块时，它都会不断添加到我们所有 PNG 文件的开头，这导致浏览器阻塞并且无法显示它们。更正 MIME 类型可以完全解决问题。text/htmlimage/pngmod_proxy_htmlmod_proxy_htmllibxml2<html><body><p>
我们从未发现 AJAX 失败的确切原因，因为一旦我们修复了 PNG，它就会重新开始工作。我们的 AJAX 代码通常通过 Apache 从 WS4D 服务器加载 HTML 片段。在我们修复 PNG 之前，它会显示一条错误消息，通常只有当 AJAX 请求返回错误代码时才会显示。我们的理论是 HTML 片段中的损坏的 PNG 以某种方式产生了错误，但我们无法验证这一点。
带走：如果您打算使用mod_proxy_html，请仔细检查您的 MIME 类型！