httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: story posted
Date Thu, 06 Feb 2003 19:57:52 GMT
At 12:15 PM 2/6/2003, Bill Stoddard wrote:
>Aaron Bannert wrote:
>>On Wednesday, February 5, 2003, at 08:39  AM, Bill Stoddard wrote:
>>>Then reimplement PHP as a handler/generator. You get the benefits of being able
to install downstream filters w/o the headaches of implementing a filter.  Personally I never
thought implementing PHP as a filter was a good idea to begin with. yea, it's more flexible
but that flexability comes at a high cost. And if no one is interested in what that extra
flexability gains you, then the only thing accomplished is the code is more complex and bug
prone. You know the saying "if the only tool you have is a hammer, then all problems look
like nails"?  Well for a while, apache 2.0 filters were 'the hammer'.  
>>>Hopefully that is changing now.
>>I don't see how making it a handler will fix this problem.
>>PHP will still want to read input bodies from the input
>>filter chain.
>>Also, I should point out that something as seemingly simple
>>as an SSI file that includes multiple php scripts needs the
>>filter stack.
>So is that a popular configuration in use with 1.3 today?  If not, then I hold this up
as a trophy illustrating my earlier assertion regarding overengineered 'solutions' to non
existent problems.

Exactly.  Yes - a 'real' PHP filter would be terrific.  In the meantime that
'filter' is broken, because it only accepts one file bucket.

The PHP Apache hackers should take a page from the jakarta connectors
flavors.  If you want rock solid, use mod_jk.  Experimental new efforts?  You've
got mod_webapp and mod_jk2 (APR based - even for Apache 1.3).

Why toss the 'stable' and 'proven' php4apache, when you can simply port
it to 2.0 and provide PHP content today?  Sure - when folks want svn backing
their PHP scripts you need a filter.  But that should have been the "what we
are doing next" instead of treating Apache2 filters as the nail and trying to
be something it's not.

Now we have the worst of both worlds... php4apache2 can't filter non-fd based
buckets - so it's essentially broken for alternate script stores.  But it doesn't
do the filtering very cleanly either.

Perhaps it's best for someone to simply port php4apache to 2.0 and start
moving a little momentum.  The thread-safety arguement is a little bogus,
until folks have something to start finding thread-safety bugs.  How long
have Win32 users been doing PHP within threaded servers?


At 11:50 AM 2/6/2003, Aaron Bannert wrote:

>There is no such thing anymore as a handler in Apache 2.0, am I correct?
>Aren't the handler-like hooks that try to behave the same was as they did
>in 1.3 just implemented over output filters?

Ummm... look at mod_info or mod_status.  Sure you can deal with
brigades instead of the ap_rwrite APIs, but that doesn't mean that
handlers don't exist.  For that matter, what about mod_cgi?

php4apache2 is going through httpd's default handler and filtering that
result brigade.  Simple enough for it to be its very own handler.

For example, all the XBitHack stuff really never belonged in a filter in
the first place.  That flag should really only work for handlers that want
to respect it (and the core handler doesn't know how to e'x'ecute text 
to the browser.)


View raw message