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
