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 Wed, 02 Oct 2002 00:00:32 GMT
At 03:27 PM 10/1/2002, Ryan Bloom wrote:
>On Tue, 1 Oct 2002, William A. Rowe, Jr. wrote:
>> 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.
>These are two different statements, if I am reading both
>correctly.  Please correct me if I am not.  Will, you are saying that if
>we have a PHP script, then we need to be able to do all DAV operations on
>the script.  Greg, you are saying that a PHP script needs to be able to
>satisfy a DAV request (meaning that the PHP code actually copies the
>resource, or generates the PROPFIND data).

Both Greg and I are stating that PHP should be able to serve PROPFIND,
COPY, GET, POST, DELETE, or FOOBAR requests.  PHP scripts can
be coerced into providing all sorts of useful behaviors, not the least of
which is GET.  Much like a CGI script might know how to handle DAV
or other sorts of requests.

>Assuming I am reading the two statements correctly, I agree with
>Will, but not with Greg.  There is a major difference between satisfying a
>COPY or PROPFIND request and generating a page that has accepted POST

There is a trivial difference.  Both take client bodies.

I'm not even suggesting that COPY or PROPFIND or FOOBAR should be
allowed by default, but the administrator should be able to override the
defaults if they have a script to handle such methods.

>A filter will never be able to satisfy COPY or PROPFIND, because those are
>actions that should be done in the handler phase.  However, having two
>ways to read the PHP script from disk (default_handler and php_handler),
>and run the page through the interpreter doesn't make sense.  That is why
>PHP was re-written as a filter, to allow it to take advantage of ANY
>back-end data store that we have.

That's bogus.  You REALLY can't argue that FOOBAR must be a handler
but POST must be a filter, since both take client bodies and provide response
bodies.  Pick your argument and quit waffling on the fence.

>> >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.
>I think I am missing something here.  PHP doesn't handle content
>generation.  It never has.  In Apache 1.3, PHP could read a script from
>the disk and interpret it.  In Apache 2.0, PHP _should_ be able to read a
>script from a bucket and interpret it.  

That script result wasn't generated?  What am I missing here?

>(The fact that it doesn't right
>now, is not really germane to this discussion).  

Agreed, we are discussing how things aught to work, not how they
have been kludged to work.

>>>From my reading of the statement above, you want people to be able to
>write handlers in PHP, which would find another page or script in a
>database and send it down the filter stack.  That can't be done right now,
>PHP can't write handlers that way, at least not that I am aware of.
>This BTW, is why mod_perl has both concepts, handlers and
>filters.  Handlers are used as content endpoints, they generate
>data.  Filters are used to modify data that was already generated.
>Please let me know if I have misunderstood anything in this
>mail.  Everything I have said above is based on my reading of the message,
>and I tried to point out where I may have not understood what the original
>author was saying.

Greg and I are really in the same place, but arguing opposite solutions
{we agree all these cases should be consistent, and Greg argues that
the answer is handler+filter, while I argue the answer is remains filters.}


View raw message