httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Sutherland <>
Subject Re: [module porting] mod_proxy
Date Tue, 14 Mar 2000 17:14:03 GMT
On Tue, 14 Mar 2000, Chuck Murcko wrote:

> James Sutherland wrote:
> > 
> > Is a full-blown Apache setup the right solution here, though, if it is
> > really just buffering the network data? Would a better approach not be to
> > have a very simple, lightweight front-end reverse proxy (more or less just
> > accepting connections, then passing data back and forth)?
> > 
> > (As I said earlier, an SSL version would be nice too, allowing a more
> > effective division of labour between multiple machines.)
> > 
> Minimally, a useful proxy will support https and ftp as well as http. It
> should (and I believe this is an enhancement) also support free
> translation between client and server protocols where possible. Proxying
> https is usually transparent by definition.
> The nontransparency of a proxy using an apache thread/process is IMHO an
> advantage in that protocol handlers defined for the proxy can be used
> elsewhere, and vice versa. Not to mention other APR functions already
> available.
> Consider the case of an SSL encrypting/decrypting proxy. Why rewrite the
> wheel when mod_ssl or Apache SSL will already have provided many of the
> necessary functions?

Sorry - I wasn't meaning a full-blown proxy. Rather, I was thinking in
terms of the setup many big Apache installations use - a reverse proxy
front-end, with "full size" Apache backend servers. This proxy doesn't
handle FTP, or indeed connections to anything other than the backend
Apache daemons.

Let's imagine an HTTPS based webmail service:

Encrypted connections are made to the front end boxes, which just do
encryption and buffering, passing the (plaintext) data back to the
mod_perl servers which generate the dynamic content, etc. This way, you
have lots of powerful front-end servers doing the heavy number crunching,
but with very simple software (just an SSL encryption/decryption and
buffering daemon.) Then you have some mod_perl boxes generating actual
content. Much "heavier" processes, but (due to the buffering and
encryption being handled externally) requests are completed very quickly.

Alternatively, simple load balancing:

A few front-end boxes reverse proxy a large number of mod_perl systems,
generating dynamic content. This time, the front end boxes just handle a
large amount of traffic, doing simple buffering for the backend machines.

Neither case calls for a full Apache server for the front end - the
latter, in particular, is nothing more than a buffered relay, but for the
ability to pass information like the remote IP address etc. to the backend
machines. Squid comes fairly close, but can't handle the encryption for
the first case, and isn't transparent - the backend boxes see and log
incoming connections from the front-end, not from the client.


View raw message