httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: PHP POST handling
Date Tue, 01 Oct 2002 22:19:39 GMT
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

> >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.

> 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)


Greg Stein,

View raw message