httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Sutherland <>
Subject Re: [mod_proxy] Help offered
Date Wed, 07 Feb 2001 22:40:42 GMT
On Wed, 7 Feb 2001, Gabriel Russell wrote:

> At 01:11 PM 2/7/2001 +0000, James Sutherland wrote:

Eh? The next quote was not mine!

> > > > There 2 jobs share some common code/functionnality but there are also

> > quite
> > > > different.
> Where they do share common code functionality, it's often not totally 
> perfect. Looking at the code I see no compelling reason to have one code 
> base for these two functions. Caching is the one obvious section that is 
> clearly sharable by the two sections.

Not even that, perhaps - the nature of caching needed is very different.

> Forgive me for stating what may be obvious to everyone else but, Ideally, 
> I'd like to see three modules:
> A caching module with a generic api, such that it folks can write drop in 
> replacements for the standard shipped module. People could then also use 
> this module in any other module that could benefit from it, caching cgi, 
> caching internal redirect, blah blah blah.
> A gateway module, just the relatively small bit of code to do proxypassing.
> A proxy module, most of the current functionality, minus the cache and 
> proxypass code.
> Not only do I think that this makes much more sense then the current 
> monolithic module, but I think that it would be significantly easier to 
> find a maintainer for each smaller module.

I suspect a better solution would be a very simple, standalone daemon
acting as an "http router" - just accept connections and proxy the data
to/from a backend server (or a cache, perhaps) based on the request's
nature (source IP, URL requested, backend load levels, whatever). I'm
actually writing something which could do this anyway (in the very early
stages, though!).


Various policies available to decide how to handle each request:
* Backend server load
* Source IP - redirect to a nearer mirror, perhaps
* URL requested - separate static and CGI requests
* Cache - if we've got a suitable cached item, send that



View raw message