Chuck Murcko wrote:
> Right now the multiplexer (the protocol selector) in mod_proxy.c is
> hardwired, so you have to touch it everytime you add a new protocol.
>
> This particular filter should read config to know what protocols it has
> (or something else I forget that Victor, Ian, and I talked about last
> week) and be able to build the protocol processing filter chain (they
> won't always consist of only a content generator, consider SSL
> decrypt->HTTP proxy).
We have this already :)
Right now what we call a "content generator" is simply the "centrepiece"
(or MPM module) of two filter chains:
+---------+ +---------------+ +-------------+
| Backend |---->| Back filters |--->| MPM modules |
| Server |<----| - DECHUNK |<---| - HTTP |
+---------+ | - SSL/TLS | | - FTP |
| - etc | | - LDAP |
+---------------+ | - SQL |
| - CONNECT |
+-------------+
| ^
v |
+----------+ +----------------+
| Frontend |<--------| Front filters |
| Server |-------->| - PROXY_DIR |
+----------+ | - GZIP |
| - CHUNK |
| - CACHE |
| - SSL/TLS |
| - etc |
+----------------+
Adding SSL/TLS support in theory is as simple as adding the relevant
filter into the back filter chain if an https:// is detected - this is
currently done with the DECHUNK filter to handled chunked responses from
downstream
servers, and with the PROXY_DIR filters to turn ASCII directory listings
from proxy_ftp into pretty HTML directory listings.
Adding SQL or LDAP support is a different story. There is no reason why
an LDAP or SQL backend has to be in mod_proxy in the first place, they
could quite well be in their own modules - but - the mod_proxy module
has most of the framework necessary to get all this to work. If the
mod_proxy support routines were placed in a library or framework that
could be shared then this could work.
Hmmm - I think I get what you're after. Right now there is a big select
framework in mod_proxy.c that selects between http, ftp and connect (and
then LDAP and SQL). This is hardwired. Can this be constructed so that a
scheme handler could be installed, that would be called based on scheme?
These scheme handlers wouldn't be filters, but hooks that will be
installed if present, ignored if not. A module would link a hook with a
handler and a scheme. This should be really easy to do - just gotta
figure out how the hook APIs work :)
Let me start playing...
> Well, Theo (mod_backhand) might disagree with you there. So would I, as
> building up and tearing down the connections can be a substantial impact
> when the messages are short (like HTTP requests) and the net load is
> high. Mod_backhand does a bit of work to insure machine load stays
> balanced.
Hmmmm - ok then the connection pool will have to be part of the load
balancer. There are placeholders in the code for where a load balancer
should go.
I am still really keen on keeping then core proxy module as simple as
possible, putting enhancements into external filters or hooks. One of
the main problems with the v1.3 proxy was that feature creep had
cluttered the code until it stopped working reliably.
> Another case I can think of is cache synching amongst a cluster of
> caches, it could be useful to pool those connections.
Is there not a special protocol for this? Squid supports cache syncing,
yet another bunch of three letter acronym protocols...! :)
Regards,
Graham
--
-----------------------------------------
[EMAIL PROTECTED] "There's a moon
over Bourbon Street
tonight..."
