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 generation. > >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 regression. (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) Cheers, -g -- Greg Stein, http://www.lyra.org/
