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 18:12:46 GMT
On Tue, Oct 01, 2002 at 01:34:20PM -0400, Ryan Bloom wrote:
> On Tue, 1 Oct 2002, Greg Stein wrote:
> > The default_handler is broken. If you POST to a resource, it returns the
> > resource. That isn't right.
> > 
> > But the PHP point is a good one. So how do we prevent a POST from returning
> > the resource, yet make it available for PHP?
> > 
> > I think that we have a model problem here. For a POST method, you need
> > something to *handle* the POST. Somebody actually needs to accept the posted
> > content, do something with it, and then *generate* a response. That response
> > might actually have other filter processing to apply to it.
> > 
> > It almost seems like PHP needs to act as a handler for POST requests (to
> > deal with the posted content), and as a filter for GET requests.
> > 
> > Does that seem right?
> No, it doesn't seem right.  The default_handler is designed to deliver a
> file from disk down to the next filter.  In the case of filters, we have
> extended the handler to work for POST and GET requests, because that is
> how filters work.

If we want this design, then all right. But it only works if we have
something to intercept the POST if nobody handles it. If a filter does not
handle the POSTed request body, then we need to return 405 (Method Not

IOW, alter the handler as I suggested, or have another filter to figure out
that the body wasn't processed and to rejigger the response into an error
response. That latter design for turn-into-error seems a bit hacky, tho,
which is why I suggested the handler mechanism.

> The assumption is that if it is a POST request, and the default_handler
> gets the request, then there is a filter that will actually run the
> request.  This works, and has worked since we introduced filters, and
> converted some handlers to filters.

Well... by this logic, we need to fix the default handler to *also* deliver
files for PROPFIND, PROPPATCH, REPORT, etc. It is just as easy to argue that
a PHP script can/should handle those requests, too.

I simply don't think that a filter should read/consume a request body. The
handler is responsible for handling the request, which includes processing
the body.

> The bug is in mod_dav.  It is trying to handle too many requests.  There

Yup. You fixed it, but that also broke the lock-checking. But no biggy --
you didn't know and that is exactly why you asked for a review :-)  I'll get
that extra check behavior put back in.

Ideally, we should have a hook that runs around fixup time which says
"should this request be handled?" That hook would be used for "if" header
processing (If:, If-Matches:, If-Not-Modifed:, etc), and it can be used for
checking WebDAV locks.

Currently, the handlers are doing all this stuff by calling
ap_meets_conditions(). That will check some of the If-* headers, but not
WebDAV's If: header. And if a handler forgets to include the call to
meets_conditions, then it is "broken".

> Because I don't believe there was a bug in the default_handler, it was
> working as designed.

Well, it delivers files for POST, sure, but nothing stopped that from
getting to the client if nobody handled it.

> The default_handler assumes that it will be run
> last, and that other modules will have an opportunity to serve the request
> if they are supposed to.


> I am not trying to show that I have all the answers, but in this case, I
> did the research, and I found the bug.  And, I do have a VERY strong
> opinion about how it should be solved.  Filters introduced some
> intricacies that weren't in the server before.  If we leave the change in
> that was made to the default_handler, nothing will be fixed.  If we add a
> new handler that handles POST requests for PHP, what does that get us?  It
> wouldn't have stopped the bug that we are discussing.  At best, it would
> have changed the response the server gave to the user.  However, that is
> only if the request was for a CGI script.  In the case of PHP, php
> requests were working before my fix, because the default_handler was doing
> it's job.  
> With the fix to the default_handler that is in place now and without the
> mod_dav fix, both CGI and PHP are broken.  Without the default_handler fix
> and without the mod_dav fix, Just CGI are broken.  With just the mod_dav
> fix, and without the default_handler fix, CGI and PHP work.  With both
> fixes, CGI work and PHP are broken.
> You want to fix PHP scripts now by adding a new handler for PHP.  Would
> that be specific to PHP?  If so, then there are two ways to run PHP
> scripts.  No thanks.  If not, then I fail to see what is being fixed.

I think we're refining our handling. These intermediates are broken in one
way or another, but we're getting there.

About a month ago, before we started messing with mod_dav's decision making
for handling, we had some problem or another (I forget what). Then Justin
and I started monkeying with it in mod_dav, and we lost the "dav-handler"
thing, and that threw off mod_dir because it jumped in when it shouldn't
have. Then we put the dav-handler back in to prevent mod_dir from doing the
work thing, but then that broke POSTing to a CGI in a DAV-enabled area. You
fixed that, but broken lock checking during a POST. I thought that covered
up a bug in default_handler, so I fixed that, but still need to go back and
fix the lock-checking. The change to default_handler broke PHP.

Whew :-)

Really... I think that anything which reads the request body ought to be a
handler. It is the one and only thing handling the request. You can't have
multiple people reading that body.

Consider it this way: the handler represents the resource. It handles any
method applied to that resource.

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.

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.


Greg Stein,

View raw message