Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <4330DC4E.8000702@rowe-clan.net>
Date: Tue, 20 Sep 2005 23:06:38 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: Issues for 2.1.8
References: <432DDB20.8020901@force-elite.com>
 <433077FC.3040102@rowe-clan.net> <43308150.2030505@gmx.de>
 <200509202327.56350.nick@webthing.com> <433090D4.1040403@rowe-clan.net>
 <4330986D.8030309@sharp.fm>
In-Reply-To: <4330986D.8030309@sharp.fm>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Graham Leggett wrote:
> 
> The majority of bugs in the v2.0 proxy code originated when a vendor of 
> an HTTP protocol testing suite added each individual protocol violation 
> they picked up to bugzilla. This makes proxy one of the most scrutinised 
> pieces of code in the server. Many of these violations were fixed, with 
> the more minor ones being still outstanding.

Please don't confuse my weeks of effort, originating from my manual
inspection (not automation) of the 'unusual' traffic patterns, combined
with third party observations in the security community, with any
detailed review of mod_proxy as a whole!  If you believe that I've
had a major impact on the stability or quality of the entire proxy
framework you are demonstrating that you truly don't know 5% of the
lines within the proxy module and are entirely ignorant of the many
complaints in our bugzilla w.r.t. various specific behaviors.

>>  * ssl   - I'm under the impression (and could be wrong) that most of
>>            the ssl issues are unusual, more experimental configurations
>>            using features that even the mod_ssl project doesn't build
>>            by default ;-)
> 
>> So they are new.  Why does that make them experimental?

because the author hacked them in as a cool idea, while not entirely
investigating all of their side effects, and the mod_ssl community had
burried them within #ifdef SSL_EXPERIMENTAL_XXX feature flags?

> Remember that there is a big difference between "works" and "works 
> well". Cache for example has worked well enough for light load servers 
> for a long time, but cache is not (yet) good enough for CNN.

The problem is that cache in 2.0 never worked at all once it 'filled up'
- showing the author truly never took the module through it's paces.

> We need an incubation process of some kind for new code that people who 
> are brave enough might try and use in production, without having to jump 
> the whole way in and install trunk onto production. That process up till 
> now has been the experimental directory. Without that directory, we 
> would have had no ldap and no cache.

Yes, yes, yes!!!  Now let's discuss incubations processes - in yet
another thread unrelated to general availability release  - and find
the way that 'cool new stuff' will truly be tested, fixed and finally
brought into the core :)

>> If you want to commit non-working, experimental code, then we can always
>> roll another sandbox to 'play' in until there is something worthy of
>> inclusion in trunk.
> 
> A sandbox nobody can play in, because it implies running a development 
> version of the entire webserver, rather than just a 
> development/experimental version of a single feature.

So let's engage Mr. Temme and his idea of a CPAN-ish modules facility?

The folks were thinking of a mechanism to bring in third party mods.
But what about our own, experimental, somewhat unstable, or simply still
moving target sandboxes, which keep growing new features too quickly?

If we are our own first consumer of a CPAN-ish Apache modules facility,
I'll wager we would do a better job anyways :)

Bill