On Tue, 1 Oct 2002, Greg Stein wrote: > On Tue, Oct 01, 2002 at 11:03:16AM -0400, Ryan Bloom wrote: > > On Mon, 30 Sep 2002, Greg Stein wrote: > >... > > > For this particular case, the bug is in default_handler(). Plain and simple. > > > There is no reason for a POST request to return the file contents. Yes, the > > > system should also call the thing as a CGI script, in this case, but that > > > doesn't excuse the default handler. > > > > No Greg, I'm sorry, but the bug has nothing to do with the > > default_handler. Plain and simple. If mod_dav wasn't in the server, the > > default_handler would never be called, because mod_cgi would have been > > given an opportunity to handle the request. The bug is in mod_dav, and no > > fix anyplace else will actually solve the problem. > > mod_dav causes the bug in default_handler to be exposed.
Nope. The default_handler relies on other handlers to run first, so that it only gets the requests it is supposed to get. Even if we change the default_handler to only serve GET requests, the bug still exists, because the bug is in mod_dav. > A secondary issue is how mod_dav alters the dav-handler in a way which > disables POST to a CGI. You've fixed this latter issue (altho it breaks the > RFC 2518 requirement of checking locks before allowing a POST). I think we > should figure out a different hook to use for that check. > > While the "fixups" hook isn't really intended for this, it would seem a good > place to do the check. mod_dav already hooks it, so that should be fine. The fixups hook is definately intended for this. The handler phase is only intended for actually generating content. Mod_dav isn't generating content for a POST request, thus it shouldn't be trying to handle it in the handler phase. Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 -------------------------------------------------------------------------------
