I have a number of web applications that need to sit behind a reverse proxy, like so:
http://example.com/app1/
=> http://appserver.example:8801/
http://example.com/app2/
=> http://appserver.example:8802/
These applications use two types of redirects:
- A root-relative redirect, e.g.
/foo
, that needs to be mapped back tohttp://example.com/app1/foo
- An absolute redirect, e.g.
http://external.example/bar
, that needs to remain untouched
I currently have a set of proxy rules defined via macro like so:
<Macro AppProxy $alias $target>
RewriteRule "^/$alias$" "/$alias/" [R=308,L]
<Location /$alias/>
ProxyPass http://$target/
ProxyPassReverse http://$target/
ProxyPassReverse /
ProxyPassReverseCookiePath / /$alias/
</Location>
</Macro>
Notably, I expect the ProxyPassReverse /
directive to accomplish my goal. However, what actually happens is it also modifies the absolute redirect:
/foo
is correctly mapped tohttp://example.com/app1/foo
http://external.example/bar
is incorrectly mapped tohttp://example.com/app1/bar
What do I need to do to preserve the first mapping but avoid the second?
Not entirely relevant, but the external redirects are required for federated authentication via e.g. SAML with customer IdPs. The internal redirects are used in the application and we would rather handle the remappings at the reverse proxy level than have the app itself worry about what its public-facing URL actually is.
Looks like this is a known bug in httpd 2.4, but there's been no activity since it was reported in 2014, so at this point I'm looking for alternatives to achieve sane redirect rewrites.
As a workaround, it's possible to manually rewrite the
Location
response header usingmod_headers
: