At 01:12 PM 10/1/2002, Greg Stein wrote: >For PHP, we said "make it a filter [so the source can come from anywhere]". >I think we really should have said "for GET requests, allow it to be >processed by PHP." The POST, PROPFIND, COPY, etc should all be possible to handle by >PHP, which means that PHP also needs a handler.
Agreed, if you write a PHP script we better allow you to PROPFIND or COPY the puppy, in addition to POST. It doesn't mean we need a handler. We need to know if something is expected to be coming down the wire at one of our filters. Maybe more than one of our filters. One of my itches that I haven't had time yet to scratch is to implement the apreq filter to expose the post (propfind, copy, etc) data to one or more than one filter who -might- be interested in the client request body. >Heck, PHP should also be able to handle a GET request. For example, it >should be able to retrieve the content from a database, and then shove that >into the filter stack. > >IOW, PHP is really a handler *and* a filter. It can handle the generation of >content, but it can also process generated content when that content is a >PHP script. That sort of misplaced design ends up exposing two fault points, one in the PHP handler, and one in the PHP filter. Better one source of pain. That said, it is -still- a handler since it just picks up the fd out of the sendfile bucket and processes that file. Until the zend mechanics are in place to slurp from brigade -> output results, this never really belonged as a filter anyways. And that said, you can't break POST to the default handler, please revert that change. Bill
