Re: mod_proxy: proposal for v2.0

[Tony Finch <do...@dotat.at>]

Graham Leggett <mi...@sharp.fm> wrote:
>
>What I had in mind was an entirely new module. RFC 2616 calls a reverse
>proxy a "gateway", so I figured I would copy the existing code to
>mod_gateway and try a clean implementation, using the existing one as a
>guide.

Would it be feasible to split the proxy stuff into three parts: a
common client back end (which would have sub-parts for http/ftp/etc.),
and two middle ends for proxying and gatewaying that interface to
Apache's core (i.e. the front-end)? That could bring the whole thing
closer to Dean's http router concept.

Tony.
-- 
               **                              **               
***   ***   ***  **** ***   *******   ***   ***  **** ***   ****
   ***   ***         *   ***       ***   ***         *   ***    

Re: mod_proxy: proposal for v2.0

[Graham Leggett <mi...@sharp.fm>]

Tony Finch wrote:

> Would it be feasible to split the proxy stuff into three parts: a
> common client back end (which would have sub-parts for http/ftp/etc.),
> and two middle ends for proxying and gatewaying that interface to
> Apache's core (i.e. the front-end)? That could bring the whole thing
> closer to Dean's http router concept.

This is pretty much what I am trying to do. The http handler is what
I'll be working on first - adding an ftp, connect, etc handler after
that won't be difficult.

Features I am aiming for in the complete implementation include:

- Optional shared memory support (caching in-transit objects and normal
objects)

I will be building the cache itself into the core, and later I plan to
use this memory cache elsewhere to replace mod_mmap_static. (Objects on
disk will be cached in shared memory, and refreshed from disk using the
normal pragma and content-control headers). This will be built into the
module that ships disk based data to clients, and also mod_includes.

- Optional on-the-fly file compression support:

Using content-encoding the module will optionally compress on the fly
data from certain specifiable MIME types (such as text/html and
text/plain, but not image/jpeg). This way Apache can be used as an
accelerator (literally) in front of dynamic generated websites that
produce large amounts of text data that normally gets sent uncompressed.

- Optional on-the-fly image filtering support:

It will be possible to filter images as they pass through the proxy, eg
change color GIFs or jpegs into monochrome for the benefit of a "low
bandwidth" version of a website.

- HTTP/1.1 cache-control support:

Support for cache control directives.

As you can see - big plans. The current code cannot be stretched further
without enormous confusion all round, so I am using the existing code as
a skeleton I am rebuilding it.

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight...