Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 17405 invoked by uid 500); 13 Aug 2000 20:09:05 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 17394 invoked from network); 13 Aug 2000 20:09:03 -0000 Sender: minfrin Message-ID: <3996FE9D.D716624F@sharp.fm> Date: Sun, 13 Aug 2000 22:01:33 +0200 From: Graham Leggett X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.17pre13 ppc) X-Accept-Language: en MIME-Version: 1.0 To: new-httpd@apache.org Subject: Re: [PATCH] mod_proxy talking HTTP/1.1 to clients References: <3996AC66.26DC91E5@elmar.co.il> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N Eli Marmor wrote: > I think that it is very important that somebody (Christian and > Graham) finally spend some effort in this module. It looked like > an "orphan" recently, and some people even suggested that because > nobody takes it under his/her responsibility, to axe out the > forward proxy stuff, and to leave only the reverse-proxy. There > are too many users who need this module and can't migrate to squid, > and with the new features (e.g. filtering) there will be so many > possibilities, so it is a too good thing to give away. I've been taking a bit of a break for a few months, but I'm certainly still around, so mod_proxy still has people who care about it :) What's happened with the development of mod_proxy is that it seems to have outrun itself - people are planning things and designing things without taking it to the next logical step - putting the mod_proxy (with HTTP/1.1 and Keepalive) in Apache v2.0 as it stands now. A lot of discussion has gone into the caching in mod_proxy - however I believe that caching is a general issue that is a project within itself. I'd like to see a genaral shared memory caching mechanism that works Apache wide, to replace mod_mmap_static with a layer that can cache anything in shared memory, not just files, using the already exisiting Cache-Control header mechanisms in RFC2616. But - this effort should not get in the way of moving the existing proxy code to Apache v2.0. So, the next step is porting mod_proxy to v2.0. I know some attempts were made to do so in the past, but I would like to see happen is that the existing mod_proxy should be ported lock stock and barrel to v2.0 - without the distractions of trying to "improve" it along the way. If we keep doing that, mod_proxy in v2.0 will never happen. Does a "how to port to v2.0" HOWTO exist anywhere? Specifically focused on how to incorporate a new module into the ./configure build system? Regards, Graham -- ----------------------------------------- minfrin@sharp.fm "There's a moon over Bourbon Street tonight..."