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:03:43 GMT
On Tue, Oct 01, 2002 at 04:27:15PM -0400, 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).
> Assuming I am reading the two statements correctly, I agree with
> Will, but not with Greg.

Why couldn't mod_dav be implemented in PHP? I see no particular reason why
not... Currently, PHP cannot because it is a filter, not a handler.

[ and yes: you should be able to manage the *scripts* using DAV operations;
  typically, you do that through a different vhost or path on the server so
  that you don't confuse GET between "GET source" and "GET output" ]

> There is a major difference between satisfying a
> COPY or PROPFIND request and generating a page that has accepted POST
> data.

Actually, I see little difference. A POST method accepts posted data and
generates a response. PROPFIND accepts data and generates a response. COPY
is mostly header-based, but I certainly don't see COPY being handled by a
filter :-)

> A filter will never be able to satisfy COPY or PROPFIND, because those are
> actions that should be done in the handler phase.

What makes these different from POST? If you can articulate that, then I'll
be able to understand your POV much better.

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

In this case, you're saying "content generator provides script. execute
script." But how do we get PHP to be a content generator? Should PHP never
be able to act as a content generator?

How do we get PHP to yank a Perl script out of a database and feed it to

Heck... we don't have enough resolution in our codebase right now. How do we
write a DAV provider in PHP, and store those scripts in SVN? In other words,
I want SVN to provide the raw content (but not act as a DAV provider), then
have that content executed by PHP to operate as a DAV server.

There is a lot of fuzziness in the early stages of the filter stack. Where
is the line between a handler and the beginning of the stack? How many
stages does the server go thru before the initial content is found? For
example, a disk file contains a PHP script which is a DAV server which loads
the content out of a database which is a Perl script to generate content.
That content is then SSI-processed, gzip'd, and then shoved onto the wire.

If there is no request body, then the line between handler and filter stack
just isn't there. You just kick an EOS brigade into the filter stack and the
first filter inserts content before the EOS (say, by reading it off disk).
When you get a request body, then it becomes a bit more difficult as it
would be "neat" to pass that through the filter stack, but it becomes hard
to distinguish between the input and the generated content.

Blah blah. I'm a bit off track there. There is one entity in the request
processing which is responsible for managing the request body. Everything
else is about altering the resulting output. Who handles the request? It
can't positively be the content generator, as we said that we want to load a
script, and have that script be the handler (e.g. handle PROPFIND).

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

In 2.0, we have a thing called "content generation" which means "generate
the script content." In 1.3, that was wrapped into the processing of that
script. So yes... PHP used to handle the concept of content generation, as
we know it in 2.0 today.

By moving PHP to a filter, we simply allowed the script to be located
anywhere. But I don't think the filter is the right place to handle *all*
types of PHP requests. e.g. POST or PROPFIND

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


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

Yup, cuz we moved the integration point of PHP. But there is nothing
inherent in PHP which should prevent this.

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

It all seems fine, but I don't understand your POV on why POST is different
than, say, a WebDAV method. And if you agree that DAV methods shouldn't be
handled by filters, then why POST?

That seems to be the only point of question. I've blue-skyed some richer
behaviors of mixing content generation and script interpretation, but the
core question seems to boil down to where POST is handled.


Greg Stein,

View raw message