Наша компания в настоящее время поддерживает (очень старое) приложение для работы с базами данных с веб-интерфейсом, написанное в 4th Dimension (2003) со встроенным веб-сервером (предоставляемым расширением Web Server 4D). Поскольку веб-сервер не поддерживает SSL, наш клиент настроил Apache для обработки внешних HTTPS-соединений (через <VirtualHost>) и направить весь трафик на сервер WS4D через HTTP, используя mod_proxy. Маршрутизация работает отлично.
Проблема в том, что сервер WS4D часто выводит неработающие URL-адреса при создании страницы. Поскольку сервер WS4D не знает об Apache, всякий раз, когда он распечатывает полный URL-адрес (включая домен), он распечатывает внутреннее доменное имя и номер порта в URL-адресе вместо внешнего (например, http: // локальный: 9999 / домашний вместо того 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> теги в источнике изображения исчезнут.
Это была проблема типа MIME. Сервер WS4D передавал все PNG в Apache с помощью Content-Type из text/html вместо того image/png, что вызывало mod_proxy_html интерпретировать их как файлы HTML и анализировать их. По-видимому, mod_proxy_html автоматически пытается исправить неправильный HTML, добавляя любые недостающие теги в начало файла, чтобы соответствовать спецификации HTML (возможно, это побочный эффект использования libxml2). Каждый раз, когда мы включали модуль, он продолжал добавлять <html><body><p> в начало всех наших PNG-файлов, из-за чего браузер зависал и не отображал их. Исправление типа MIME полностью устранило проблему.
Мы так и не выяснили, почему именно наш AJAX давал сбой, потому что как только мы исправили PNG, он снова начал работать. Наш код AJAX обычно загружает фрагменты HTML с сервера WS4D через Apache. До того, как мы исправили наши PNG, отображалось сообщение об ошибке, которое обычно отображается только тогда, когда запрос AJAX возвращает код ошибки. Наша теория состоит в том, что сломанные PNG в фрагментах HTML каким-то образом вызвали ошибку, но мы не можем это проверить.
Вывод: Если вы собираетесь использовать mod_proxy_html, перепроверьте свои типы MIME!