httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: PHP POST handling
Date Tue, 01 Oct 2002 18:32:16 GMT
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.


View raw message