httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <>
Subject Re: PHP POST handling
Date Tue, 01 Oct 2002 18:54:38 GMT

how many sites are you going to break with this core.c change?
 From what I have heard the RFC says that the server can do what it 
chooses on a POST to a file. we (apache 1.3 & apache 2.042 and below) 
chose to serve a file.

Greg Stein wrote:
> 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
> Allowed).
> 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.
> Right.
>>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.
> Cheers,
> -g

View raw message