Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <3F40330B.6030209@mail.more.net>
Date: Sun, 17 Aug 2003 20:59:39 -0500
From: Glenn Nielsen <glenn@mail.more.net>
Organization: MOREnet
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2.1) Gecko/20030224
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: [PATCH] Review & Test: mod_include redesign
References: <20030817052544.0d7238ee.nd@perlig.de>
In-Reply-To: <20030817052544.0d7238ee.nd@perlig.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

I am glad to see that work continues on  fixing bugs in mod_include. :-)

The only place I have had problems is on two of our production servers.
I will have to wait until the mod_include patch is considered ready for
release (production) in the 2.0 branch before I would consider upgrading
and doing a production test.

Regards,

Glenn

Andr� Malo wrote:
> [CC to Ron Park and Glenn Nielsen to get this onto their radar]
> 
> Since it turned out that one segfault was hunting the next and mod_include
> became more and more unmaintainable, Brian Pane and I started (independently
> :) a rewrite of the filter parser. While Brian used the old design and
> external API (mostly for backwards compat) I've tried to redesign it from
> the scratch. However, we've finally decided to take the newly designed
> version.
> 
> The new code consists of a buffer centric parser (as opposed to a brigade
> centric one). There's just one main loop that knows about buckets and the like
> and passes most of the actual parser work to functions that deal only with
> buffers. The output is handled similar to mod_bucketeer; we no longer insert
> buckets somewhere in the currently parsed brigade, we just create a new one
> and append all new buckets at the end. From time to time this one will be
> passed down the filter chain. This results even in a simpler -- though
> incompatible -- external API. In order to be able to backport the
> change(binary compatible), there are just some lines wrapper code necessary
> which emulate the old API.
> 
> The new code passes all tests, except one (modules/include/#36), where I'd
> say, we should change the expectation ;-)
> (1.3 throws nothing in this test, the current mod_include throws two error
> messages and the new module throws just one error message).
> 
> I've uploaded all the code for review and test.
> 
> - plain code (for 2.1 HEAD)
>       <http://cvs.apache.org/~nd/mod_include.c> (123K)
>       <http://cvs.apache.org/~nd/mod_include.h> (5K)
> 
> - full patch against 2.1 (about 200K)
>   It contains also patches of mod_cgi and mod_cgid (because of the modified
>   API) and some other neat things like namespace protection of the public
>   parts etc. - but don't worry, once I'm committing it, it'll we splitted into
>   several commits.
>       <http://cvs.apache.org/~nd/ssi-redesign21.patch>
> 
> - full patch against 2.0 (about 70K)
>   This patches only mod_include.c and mod_include.h and only the parts that
>   are necessary to get it working. It also contains the wrapper code for
>   binary compat.
>       <http://cvs.apache.org/~nd/ssi-redesign20.patch>
> 
> Please have a look at it. Opinions, comments etc are highly appreciated.
> Thanks.
> 
> nd