Message-Id: <199803300856.KAA08248@en1.engelschall.com>
Subject: Re: [PATCH] Apache as a Reverse Proxy
To: new-httpd@apache.org
Date: Mon, 30 Mar 1998 10:56:52 +0200 (MET DST)
From: rse@engelschall.com (Ralf S. Engelschall)
Organization: Engelschall, Germany.
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org


In article <3.0.3.32.19980330001601.008b62c0@hyperreal.org> you wrote:

> At 09:34 AM 3/30/98 +0200, Ralf S. Engelschall wrote:
>>Hmmm..... yes and no. When you look at my article in the current
> WEBTechniques
>>4/98 you see that my Reverse Proxy configuration uses RewriteRule ... [P]
> plus
>>ProxyPassReverse. No ProxyPass itself because it is too less powerful. Here
>>the merging would be confusing and perhaps leads to problems.

> But I'm already confused and having problems :)  Wish the article was
> online so I could understand it, but semantically, there is a disconnect
> for me between the name of the directive "ProxyPassReverse" and what it
> actually does.  It's as if "ProxyPassReverse" should really be
> "ProxyPassRewriteRedirects"; but then it feels like something that could be
> implemented entirely using mod_rewrite calls if mod_rewrite is the only
> thing which is going to need it *and not need* "ProxyPass".

Correct, ProxyPassRewriteRedirects is a little bit ugly and not really better.

> But let's talk for a second about the solution you're discussing: 

I've posted the config from WT4/98 to apache-core for your reference.

> the
> ability to have a stripped-down Apache act as a gateway to a host of
> back-end systems.  If your selection algorithm is rand(), then why not
> instead modify ProxyPass to take arguments as ITERATE2, e.g.

>   ProxyPass /cgi-bin http://cgi1.blah.com http://cgi2.blah.com
> http://cgi3.blah.com

> seems as though this is a simpler solution, *from the viewpoint of the
> person editing and maintaining config files*, than involving mod_rewrite.  

> This, like the "virtual vhost support" issue from awhile back, harken to my
> issue with the temptation to see everything as a nail and mod_rewrite as
> the hammer.

Hmmmm.... when you look at the config in depth, you notice that at least these
tree rewriting rules do a lot more:

CustomLog      /path/to/apache-rproxy.dlog "%{%v/%T}t %h -> %{SERVER}e URL: %U"
RewriteRule    ^/(.*\.(cgi|shtml))$  to://${server:dynamic}/$1  [S=1]
RewriteRule    ^/(.*)$               to://${server:static}/$1
RewriteRule    ^to://([^/]+)/(.*)    http://$1/$2   [E=SERVER:$1,P,L]

First the decision is not prefix based: it's suffix based. Second the final
delegation rule additionally writes the logfile entry via its E=SERVER flag.
For the article I really thought about directly enhancing ProxyPass. But then
I discovered that mod_rewrite can do all except for the random selection. And
because random selections can be useful in other situations, I decided to give
our Swiss Army Knife of URL manipulations just a little sub-knife more.
Because this way we can provide the reverse proxy feature with maximum
flexibility _and_ don't restrict the random-feature to just this special
situation.

Sure, I know what point you address, Brian. This is acceptable. Of course I'm
biased when using mod_rewrite.  But I still think it was the correct location
to add this functionality. Nevertheless you are right, too: It would be nice
to also have this functionality in the much simpler ProxyPass directive
because its easier to understand. On the other hand, people setting up reverse
proxies have to understand a lot more then ProxyPass. So perhaps its no harm
that they also have to use mod_rewrite...

Greetings,
                                       Ralf S. Engelschall
                                       rse@engelschall.com
                                       www.engelschall.com