0

I am implementing a reverse http proxy:

proxy.example.com

This will forward requests to servers based on URI:

proxy.example.com/server1 -> server1.example.com

When a user requests proxy.example.com/server1, server1 sends a programatically generated (Ruby Devise Gem) 302 response with the following "Location" value:

proxy.example.com/users/sign_in

I need this to be:

proxy.example.com/server1/users/sign_in

I have implemented the following config in Apache:

ProxyPass "/server1/" "http://server1.example.com/"
ProxyPassReverse "/server1/" "http://server1.example.com/"

as per:

http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypassreverse

"This directive lets Apache adjust the URL in the Location, Content-Location and URI headers on HTTP redirect responses. This is essential when Apache is used as a reverse proxy (or gateway) to avoid bypassing the reverse proxy because of HTTP redirects on the backend servers which stay behind the reverse proxy."

But the Location header that is being returned by server1 is still:

proxy.example.com/users/sign_in

Is there something wrong with my config?

thx

  • is this a malfunction limited to devise or is the whole rails site which fails generating correct URLs? – 473183469 Nov 6 '15 at 10:17
  • I'd be surprised if it was anything to do with Devise. Apache shoudn't care how the Location header is generated. Apache should be be able to look in the Header sent from the destination server and change the subsequent Header sent to the client based on the ProxyPassReverse rule. – Garreth McDaid Nov 6 '15 at 10:34
0

Figured it out:

ProxyPass "/server1/" "http://server1.example.com/"
ProxyPassReverse "/server1/" "http://proxy.example.com/"
  • Seemps fragile, this means that if your upstream gives you an absolute uri like: server1.example.com/my/path this won't be rewriten with the correct value which should be proxy.example.com. In your case you're doing two rewrtites on your URI, one the FQDN of the server, proxy / server1 and another on the location, so /users/sign_in to /server1/users/sign_in. It's way easier if you can configure your upstream (server1) to serve your app at the same webroot, /server1 – Fredi Nov 6 '15 at 14:56

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.