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 to http://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/

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 to http://example.com/app1/foo
  • http://external.example/bar is incorrectly mapped to http://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 using mod_headers:

Header edit Location "^/" "/$alias/"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.