mod_proxy: proposal for v2.0

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

Hi all,

This has been brought up before, so with the previous discussions in
mind, I would like to put forward the following proposal for the future
of mod_proxy within v2.x.

I would like to propose the deprecation of the "forward proxy"
functionality of the mod_proxy module, reverting it to purely a "reverse
proxy" implementation.

I have found (and fixed) a few more bugs in the existing code, and plan
to do a major rewrite of it in the next few weeks. What will make my job
easier is to focus on the reverse proxy and caching behavior within the
code, which has become really convoluted and confusing.

My plans include:

- a shared memory cache in addition to the disk cache.
- upgrade to HTTP/1.1.
- extend functionality to cache (in memory) local objects in addition to
remote ones.

Does anyone violently oppose what I'm trying to do? Am I on the wrong
track here?

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

Re: mod_proxy: proposal for v2.0

[Eli Marmor <ma...@elmar.co.il>]

There are many people who use the (forward) proxy of Apache, and you
can't ignore them and force them to use other solutions. Most of them
even CAN'T use another solution, because they rely on Apache. For
example, there are modules for filtering of various conversions of
texts or docuements, which can be accessed from both the main core
(i.e. when Apache is used as a simple server and/or as a reverse
proxy), as well as the case of a forward-proxy. Such modules were not
written for squid or other proxies, because - contrary to them -
Apache can be used also as a web server, so you catch 3 birds in one
hit (support for a web server, a proxy, and a reverse proxy).

I can give many other cases where there is no alternative to Apache's
proxy. I even know many people who rely on it.

On the other hand, I agree that useless and/or non-important parts of
Apache should be axed, in order to save maintanance. Contrary to the
proxy stuff, there are parts which are not used almost by anybody, so
let's axe them. The migration to 2.0, and thhe need to re-write most
of Apache, is a good opportunity to kill these parts.

(Sorry for not naming the specific things which can be axed; I'm
afraid of being flamed by authors of these parts, and/or users of
them - although I doubt that anybody uses them at all...).

Regarding claims that our proxy is not strong enough - this problem
will not be resolved by axing it (unless you are an ostrich). I think
that mod_proxy is strong enough for usual tasks, and if anybody dis-
agree, I would suggest him to add support for, as example, transparent
proxing, or another lack of mod_proxy.

(I don't have any intention to argue; I understood the proposal as a
question: "Does anybody need it? If not, let's axe it", and my message
is an answer: "Yes, there are many users of it, and I can even witness
about many of my friends/customers/whatever who use it").
-- 
Eli Marmor
marmor@elmar.co.il
El-Mar Software Ltd.

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...

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

[Dean Gaudet <dg...@arctic.org>]

On Thu, 27 Jan 2000, Eli Marmor wrote:

> There are many people who use the (forward) proxy of Apache, and you
> can't ignore them and force them to use other solutions.

the legacy mod_proxy could be split into another package; at a minimum
mod_proxy shouldn't delay 2.0.  there's nothing stopping folks who use it
from contributing support back :)

On Thu, 27 Jan 2000, Graham Leggett 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.

this sounds great.

Dean

Re: mod_proxy: proposal for v2.0

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

Marc Slemko wrote:

> ...and then someone will come along later and want to add a forward proxy
> and then tat part will be convoluted and confusing.

Maybe.

> I really don't see the point in not supporting normal proxying.  A lot
> of people use it, despite its current problems.  I don't see how you can
> save that much implementation just by doing a reverse proxy, since to do
> that properly requires most of the work anyway, so you may as well design
> it so the whole thing works...

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.

This way the existing module can stay for the people who need it, and
the new one won't step on any toes.

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

Re: mod_proxy: proposal for v2.0

[Marc Slemko <ma...@znep.com>]

On Thu, 27 Jan 2000, Graham Leggett wrote:

> Hi all,
> 
> This has been brought up before, so with the previous discussions in
> mind, I would like to put forward the following proposal for the future
> of mod_proxy within v2.x.
> 
> I would like to propose the deprecation of the "forward proxy"
> functionality of the mod_proxy module, reverting it to purely a "reverse
> proxy" implementation.
> 
> I have found (and fixed) a few more bugs in the existing code, and plan
> to do a major rewrite of it in the next few weeks. What will make my job
> easier is to focus on the reverse proxy and caching behavior within the
> code, which has become really convoluted and confusing.

...and then someone will come along later and want to add a forward proxy
and then tat part will be convoluted and confusing.

I really don't see the point in not supporting normal proxying.  A lot
of people use it, despite its current problems.  I don't see how you can
save that much implementation just by doing a reverse proxy, since to do
that properly requires most of the work anyway, so you may as well design
it so the whole thing works...

Re: mod_proxy: proposal for v2.0

[Greg Stein <gs...@lyra.org>]

As I stated during the previous thread...

I would like to see the removal of the forward-proxy code (saving on
continued maintenance); we can easily refer people to other proxy code,
such as Squid.

Other features that can be trimmed are fine with me. But hey... your call
on what you'd like to do. I'll support any reduction in this area because
I believe it is somewhat duplicative of other open-source efforts.

I recall the prior discussion did come up with a few design points (such
as a general page cache and generalized remote page fetching).

Cheers,
-g

On Thu, 27 Jan 2000, Graham Leggett wrote:

> Hi all,
> 
> This has been brought up before, so with the previous discussions in
> mind, I would like to put forward the following proposal for the future
> of mod_proxy within v2.x.
> 
> I would like to propose the deprecation of the "forward proxy"
> functionality of the mod_proxy module, reverting it to purely a "reverse
> proxy" implementation.
> 
> I have found (and fixed) a few more bugs in the existing code, and plan
> to do a major rewrite of it in the next few weeks. What will make my job
> easier is to focus on the reverse proxy and caching behavior within the
> code, which has become really convoluted and confusing.
> 
> My plans include:
> 
> - a shared memory cache in addition to the disk cache.
> - upgrade to HTTP/1.1.
> - extend functionality to cache (in memory) local objects in addition to
> remote ones.
> 
> Does anyone violently oppose what I'm trying to do? Am I on the wrong
> track here?
> 
> Regards,
> Graham
> -- 
> -----------------------------------------
> minfrin@sharp.fm		"There's a moon
> 					over Bourbon Street
> 						tonight...
> 

-- 
Greg Stein, http://www.lyra.org/