Apache Reverse Proxy Sending Browser to Backend Directly Instead

Question

( UPDATE at the bottom for the main question, below may be superfluous details)

I'm having an interesting problem with Apache not reverse proxying as expected.

Basically, what's happening is when I click a link on my website that goes to the relative path /app1 , I am expecting it the URL to be external.company.ca/app1 with content coming from internal.company.ca/some_app . Instead, the browser is going directly to internal.company.ca/some_app .

No 302 or anything, just straight there. This is odd to me, since internal.company.ca is not mentioned anywhere in the configuration except for the reverse proxy config, so I don't know how the browser is learning of the domain at all.

Here is a Fiddler capture from the client (browser) point of view showing the behaviour right after I click the link that goes to /app1 (you'll have to trust me that the green names are external.company.ca and the black names are internal.company.com and the path is /some_app/blahblah ):

Everything happening after this point is loading the page with internal.company.com . This won't work at all in production, of course.

The following is a (truncated) version of our Apache configuration files for consideration:

<VirtualHost *:80>
    # rewrite rules to 443
</VirtualHost>

<VirtualHost *:443>
    ServerName external.company.ca
    ServerAlias external.company.com

    # Logging rules.........

    SSLEngine on
    SSLProxyEngine on
    SSLProxyVerify none

    # Most of this is off for testing purposes, adding in case it matters

    SSLProxyCheckPeerCN off
    SSLProxyCheckPeerName off
    SSLProxyCheckPeerExpire off

    # more SSL stuff.... Now on to the interesting part

    ProxyPreserveHost On
    ProxyPass /app1 https://internal.company.com/some_app
    ProxyPassReverse /app1 https://internal.company.com/some_app
</VirtualHost>

At one point, I thought that possibly the cookies were throwing things off since they were under different domains (.ca in front, .com in back), but I believe if the reverse proxying was working correctly, the browser would be none the wiser. Anyone see anything wrong with the above?

UPDATE

I found the culprit:

<script type="text/javascript">window.location.assign('https://internal.company.com/app1/login?redirectUrl=' + encodeURIComponent(window.location.pathname + window.location.hash));</script>

The problem is, how do I rewrite this absolute URL using Apache? I know mod_proxy_html modifies element attributes (such as href in the a element) but can it rewrite arbitrary data in an element itself?

The internal application was provided by a vendor, and although it may be possible to make modifications to it to remove code like the above, I would prefer to stay away from that path for now to see if there are alternatives.

Answer 1

I've come up with a somewhat nasty work-around:

ProxyHTMLEnable On
ProxyHTMLExtended On
ProxyHTMLLinks script src
ProxyHTMLURLMap https://internal.company.com

The problem is the use of absolute URL's throughout the HTML (and javascript) coming from the vendor's app. A search and removal of the domain solves the problem (but is incredibly slow).

If anyone has this problem in the future, I do not recommend using this solution. I'm guessing you're here because you can't modify the internal application. You should instead be sending in a ticket to whoever maintains the code to make their application more reverse-proxy friendly.

Answer 2

A potentially safer solution would be the use of mod_substitute . You could also consider ProxyHTMLExtended , but it can be quite brutal in its replacements, occasionally breaking JavaScript here and there.

Edit: Just noticed you're currently using ProxyHTMLExtended. My bad. As you've highlighted it is a pretty brutal and dangerous solution to the problem.