0

Our company is currently supporting a (very old) web-enabled database application written in 4th Dimension (2003) with a built-in web server (provided by an extension called Web Server 4D). Since the web server has no SSL support, our client set up Apache to handle outside HTTPS connections (via a <VirtualHost>) and route all traffic to the WS4D server over HTTP, using mod_proxy. The routing is working perfectly.

The problem is that the WS4D server often prints out broken URLs when building a page. Since the WS4D server does not know about Apache, whenever it prints out a full URL (domain included), it prints out an internal domain name and port number in a URL instead of the external one (e.g. http://localhost:9999/home instead of https://www.example.com/home). Most of the other links are relative (e.g. /img/smiley.png), and therefore work fine.

To solve this, we tried setting up a third-party Apache module called mod_proxy_html to rewrite the links with the correct domain. However, whenever we just activate the module in httpd.conf (with ProxyHTMLEnable On, but no rewrite rules defined), all of the sudden our PNGs and AJAX requests (which were working previously) fail to load! I'm not sure, but I think the server may be returning these withe the wrong MIME type.

Does anyone know how we could fix/debug this issue?

Update: I checked the links for the PNGs and, since they are relative links (e.g. /img/smiley.png), they are printing out fine. When I put the URL into my browser, however, I get a bunch of gibberish (which I presume is the binary image formatted as text). And, strangely, at the very beginning there are three HTML tags: <html><body><p>.

Update 2: The tags are definitely not being added by my browser (Safari). When I turn off mod_proxy_html, the images load in the page as normal, but still open as text when I visit the URL directly. With mod_proxy_html turned off, the <html><body><p> tags in the image source disappear.

Improve this question
7
  • Can you verify that the locations are correct from the HTML after being rewritten? Browsers are pretty smart about figuring out MIME types when the browser sends the wrong one, so I'm hesitant to blame just that. Firefox and Chrome have good debugging tools, or else maybe just capture the full request's raw data? Commented Feb 16, 2012 at 18:30
  • Well, that got me wondering! The links are printing out correctly, but when I load the individual files they show as text. And... after opening a PNG, I found that (somehow) there was a <html><body> prepended to it. Very bizarre... Commented Feb 16, 2012 at 18:49
  • Ha! I wouldn't think it was mod_proxy_html.. but it may be. Is the PROXY_HTML_FORCE env variable set? Commented Feb 16, 2012 at 18:53
  • I put UnsetEnv PROXY_HTML_FORCE right after LoadModule proxy_html_module libexec/apache2/mod_proxy_html.so in the Apache config file, but it didn't seem to change anything. Commented Feb 16, 2012 at 19:47
  • Gotcha. Can you check the MIME type on the images when mod_proxy_html is off? Something's making it think they're HTML content to be parsed, which it's gladly doing. Commented Feb 16, 2012 at 20:03

1 Answer 1

Reset to default
1

It was a MIME type issue. The WS4D server was transferring all PNGs to Apache with a Content-Type of text/html instead of image/png, which was causing mod_proxy_html to interpret them as HTML files and parse them. Apparently, mod_proxy_html automatically tries to correct improper HTML by adding any missing tags to the beginning of the file to conform with the HTML spec (probably a side-effect of using libxml2). Whenever we enabled the module, it kept adding <html><body><p> to the beginning of all our PNG files, which was causing the browser to choke and not display them. Correcting the MIME type fixed the problem completely.

We never discovered exactly why our AJAX was failing, because as soon as we fixed the PNGs it started working again. Our AJAX code usually loads snippets of HTML from the WS4D server through Apache. Before we fixed our PNGs, it was displaying an error message that normally only shows when an AJAX request returns an error code. Our theory is that broken PNGs in the HTML snippets somehow generated the error, but we cannot verify this.

Takeaway: If you intend to use mod_proxy_html, double-check your MIME types!

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.