Forum Moderators: phranque
The new urls will be:
[rp.example.com...]
[rp.example.com...]
The web1 and web2 servers will be issued a self-signed SSL certificate. Communication from rp.example.com to both web1 and web2 will be over https as well. So,
Internet <-> [rp.example.com...] <-> [web1.example.com...]
I am having a difficult time implementing this, as there are some references on web1 to /images/someimage.jpg which don't get translated to /web1/images/someimage.jpg. Further, my web2 website likes to force its name to [web2.example.com,...] bypassing the rp.example.com/web2 reverse proxy.
I've gotten some limited success in properly mapping /images, by using the following:
RewriteEngine on
SSLProxyEngine onProxyPass /web1 [web1.example.com...]
ProxyPassReverse /web1 [web1.example.com...]RewriteCond %{REQUEST_URI}!^/web1/
RewriteRule ^/(.*) [rp.example.com...] [L]
However, I still haven't figured out how I differentiate between /web1 and /web2 on my RewriteCond and how to prevent web2 from forceably breaking out of my reverse proxy. Further, while it appears to be working, I have some concerns about the Apache RP being able to talk https to an internal webserver using a dummy, self-signed certificate.
I noticed quite a number of mod_rewrite questions presented on this forum, but didn't find any which addressed the specific scenario I'm looking at.
RewriteCond %{REQUEST_URI}!^/web1/
RewriteRule ^/(.*) [rp.example.com...] [L]
One thing I've come to realize in my time on this forum; at least 8 times out of 10, you don't need a RewriteCond based on the %{REQUEST_URI}; it can all be handled in the RewriteRule.
Assuming I understand what you're going for here, you can do this:
RewriteEngine on
RewriteRule ^/(web[12])/(.*) https://rp.example.com/$1/$2 [L]
Does this help, or did I misunderstand?
In answer to another point you brought up:
Further, my web2 website likes to force its name to [web2.example.com<...]
This implies that fully qualified URLs are being used in the HTML ('https://web2.example.com/path/to/file.htm' instead of just '/path/to/file.htm'); if that's the case, you have two options:Re-work the HTML so that the protocol and hostname are removed Reconfigure your proxy server to answer for [web2.example.com...] You could do it with a stripped down <VirtualHost> block, which just proxies the request back; you can't do it any other way, since the 'https://' part means that for SSL negotiation to succeed without warnings, the browser will need to complete an SSL handshake with the host using the certificate for 'web2.example.com'.
rp.example.com is a virtual host, reverse ssl proxy. When someone connects to [rp.example.com...] any references to / should get translated to /web1. This is complicated by the fact that /web2 is also in this same virtual host.
I need the %{REQUEST_URI} statement because it looks for!^/web1 eg. the case were we have an img=/images/someimage.jpg. In that case, it would see that /web1 was not in the URI, and change this to be img=https://rp.example.com/web1/images/someimage.jpg. That way I don't have a broken image.
The problem I encounter with this is if the site really was /web2, how do I differentiate? I had thought about using a RewriteCond %{HTTP_REFERER} ^(.*)/web1/(.*) (or something like that) to make sure the right rules go with /web1. However, I'm not sure I want to rely on HTTP_REFERER, I understand that this is something a web browser like Firefox can hide.
As for the backend https:// connection from rp.example.com to web1.example.com, I'm not really convinced that SSL certificate has to be signed by anyone other than snake oil, inc. The rp.example.com SSL certificate will be genuine, signed by Verisign, but do I really need to buy 2 certificates?
So, it is essentially two questions. How can I differentiate between /web1 and /web2, and will the backend SSL handshake care about the SSL certificate not being genuine?
