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 >
