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. >>-aaron > >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? Bill 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.) Bill
