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:10:32 GMT
At 05:19 PM 10/1/2002, Greg Stein wrote:
>On Tue, Oct 01, 2002 at 01:32:16PM -0500, William A. Rowe, Jr. wrote:
>> At 01:12 PM 10/1/2002, Greg Stein wrote:
>> 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.
>As long as it is understood that only *one* thing can consume the request
>body. Then the question arises: how do you arbitrate that? It would be nice
>to simply say "the handler is the consume" but that doesn't solve the case
>of a PHP script stored in an SVN repository. It is almost like we need some
>concept of stages leading up to request [body] processing and content

Wrong.  Multiple things can access the properties from the request.
Consider some form variables.  One filter might be transforming on
variable X, while another performs some transformation on variable Z.
And they use the same storage for all small bits of the POST.

In the case of upload requests, one consumer must 'sign up' to stream
the file, and provide a method for retrieving the contents if anyone else
cares {for the duration of the request.}  In theory, that consumer is the
script that wants to persist the POSTed file upload.  If nobody wants
to capture a huge POST body, we may end up with a tmpfile method,
but if the file will be persisted, there is no reason to stow it twice.

>> >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.
>But they are two modes of operation. In one, you generate the original
>content (e.g. a PROPFIND or GET response against a database), in the other
>you're filtering content.

In both cases you are transforming a PHP script into the resulting
output from processing the script.  No difference, truly.

>> 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.
>The problem is that it isn't really "filtering" content. The filter thing
>was a hack to enable us to have PHP scripts in arbitrary locations (e.g. in
>a DAV repository). But it isn't *filtering*. It is executing the script and
>producing output.
>The notion of "take this input, munge it in some way, and produce output" is
>*very* shaky.
>> And that said, you can't break POST to the default handler, please
>> revert that change.
>The POST behavior before my fix was a regression against 1.3. Its existence
>was to support the PHP-processing-as-a-filter implementation. The impact of
>adding the POST "feature" to the default handler was never really detected
>until we uncovered it via a bug in mod_dav. Since this regression was found,
>I went in and fixed it. Unfortunately, that breaks PHP :-) But I think the
>PHP integration is broken and needs to be fixed.
>While new PHP integration is being solved, we can *temporarily* revert the
>change so that PHP users aren't inconvenienced while the integration is
>worked on. But the default_handler fix does need to go in to prevent the
>(I term it a regression because 1.3 didn't do it, and POSTing to something
> which isn't going to handle the posted content is not right; we should be
> generating an error that states the POST is not allowed for that resource;
> that is what 405 is all about)

We should continue this discussion after the change is reverted,
and let's find a better answer.

Going back to the apreq input filter, I can see where it would share
with the core if anyone registered to review the client body.  If someone
does, the handler could be toggled to accept POST.  If nobody registers,
then we could decline POST.


View raw message