httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: PHP as a filter (was: Apache 2.0 Numbers)
Date Tue, 25 Jun 2002 05:48:48 GMT
At 11:15 PM 6/24/2002, Ian Holsman wrote:
>Greg Stein wrote:
>>
>>No frickin' way. PHP is a filter, not a handler. Something else generates
>>the content, then PHP parses it and executes it.
>
>It should also be a handler because in the normal case it just reads a 
>flat file off the disk.
>so that in the >general< case you won't get the slowdown penalty for the
>people who are going to be use it ontop of something else.

You miss the point altogether.

The handler is the core FILESYSTEM handler itself.  Why on earth should
php worry about the distinction?  Whether it resides in the filesystem, the 
sql
database, the .tar archive or an SVN repository is all beside the point.

To the extent that 2.0 provides faux-handlers that make setup simpler for
old users to understand, fine.  We have that.  By 2.1 I sure as heck hope
we rip out those kludges.

The problem today is that the zend engine parses a file, not a stream.  That's
actually partly true, zend is set up for streaming, IIUC there are just a few
bits missing to actually serve the content straight into PHP's zend engine
from the brigade.  There should be no significant slowdown if the brigade
mechanics interact correctly.

Creating both a filter and handler gives you two opportunities for bugs,
security holes, exploits and the rest.  Code that works in a single modality
for multiple uses should be written in the single cleanest possible way.

Bill


Mime
View raw message