On Tue, 1 Oct 2002, Greg Stein wrote: > On Tue, Oct 01, 2002 at 12:29:53PM -0400, [EMAIL PROTECTED] wrote: > > On 1 Oct 2002 [EMAIL PROTECTED] wrote: > > > > > gstein 2002/10/01 09:24:41 > > > > > > Modified: server core.c > > > Log: > > > Fix bug in the default handler. POST is not allowed on regular files. > > > The resource must be handled by something *other* than the default > > > handler. > > > > -1. This is going to break PHP. PHP is a filter now, which means that > > the page is served by the default_handler. Since PHP requests are allowed > > to use POST, this is now broken. > > > > As I said before, the bug is in mod_dav, and must be fixed there. > > That will get fixed. I keep saying that, but you keep harping on "default > handler isn't broken". Bunk. > > 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. 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. The bug is in mod_dav. It is trying to handle too many requests. There was no bug in the default_handler. Which is why I am against putting a fix in for it. As for: "And I *already* said there is a separate issue/bug. You don't have to keep beating the damned horse and continue to disagree to try and show that you're the guy with all the answers. It's really annoying. You could just say, "yah. default_handler does have a bug, but both need to be fixed [but I already fixed the mod_dav one]"." Because I don't believe there was a bug in the default_handler, it was working as designed. 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. Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 -------------------------------------------------------------------------------