Mike Murray wrote: > Nope. The problem with this one is that the machines being proxied to > aren't reachable from the outside world; it seems that the proxypass > directives simply redirect the request, rather than doing a rewrite on the > URL on both sides of the connection. So, when I would go to: > > http:/proxy/foo, where we have: > > ProxyPass /foo https://foo > > I get the browser/traffic redirected to https://foo (which is > unavailable).
Are you using ProxyPassReverse? This will fix it for you: ProxyPassReverse /foo http://foo This will find all instances of "http://foo"; and replace it with the current servername, up to "/foo" as specified on the left. See the docs for more info. > > > 2. Using a normal SSL page to authenticate via client certs, and using an > > > .htaccess file in the DocRoot of the proxy server to auth IP addresses. > > > > This won't work - as there is no concept of a root directory for a > > proxied server. Put your directives within a <Location> tag in the main > > server. > > This sounds promising; the question, then, is what location to point at to > have the proxy reference the .htaccess file. There isn't one - .htaccess files go inside directories served by Apache. In the proxy case, there is no directory at all to speak of - so nowhere were it would make sense to put an .htaccess file. There is no requirement to use .htaccess files - just put the access control stuff into the main httpd.conf file. Regards, Graham -- ----------------------------------------- [EMAIL PROTECTED] "There's a moon over Bourbon Street tonight..."
smime.p7s
Description: S/MIME Cryptographic Signature
