You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Greg Stein <gs...@lyra.org> on 2002/10/01 00:48:29 UTC
Re: POST
On Mon, Sep 30, 2002 at 09:36:50AM -0400, rbb@apache.org wrote:
> On Sun, 29 Sep 2002, Justin Erenkrantz wrote:
>
> > On Mon, Sep 30, 2002 at 01:17:55AM -0400, Ryan Bloom wrote:
> > > Because 2.0.42 always displays script source for CGI scripts that use
> > > POST, I believe that we should put that notice on our main site, and stop
> > > suggesting 2.0.42 for production use.
> >
> > I could not reproduce your problem in my tests. Do you have a clear
> > reproduction case? (POSTing to a DAV resource for me yields a 404.)
> >
> > Is it somehow related to mounting a DAV repository at / and the
> > server getting confused about the /cgi-bin/ dir? -- justin
>
> Nope, any script that is under DAV control will post the source to the
> user.
Hunh?
The POST code in mod_dav checks for DAV locks on the resource (per RFC
2518). If there is a lock, then it returns an appropriate error. Otherwise,
it just returns DECLINED and lets (presumably) the default handler deal with
the POST request.
The bug is located in server/core.c::default_handler(). It serves up the
content of a file that you POST to. That isn't right.
Of course, we also have the problem that we can't have more than one
handler. We could restore the RFC 2518 POST check by putting that into a
different processing phase. Not sure which, tho... (it needs to be after the
authentication, at least)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: POST
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Oct 01, 2002 at 12:27:25PM -0400, Ryan Bloom wrote:
> On Tue, 1 Oct 2002, Greg Stein wrote:
>...
> > 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.
What do you mean "nope". Stop trying to be so Right. There is a bug in the
default_handler. I just committed a fix.
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]".
> > 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.
/**
* Allows modules to perform module-specific fixing of header fields. This
* is invoked just before any content-handler
* @param r The current request
* @return OK, DECLINED, or HTTP_...
* @ingroup hooks
*/
AP_DECLARE_HOOK(int,fixups,(request_rec *r))
As I said: this hook isn't quite "right", but it will serve our needs.
I'll tweak mod_dav to fix the POST checking.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: POST
Posted by Ryan Bloom <rb...@ntrnet.net>.
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 rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------
Re: POST
Posted by Greg Stein <gs...@lyra.org>.
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.
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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: POST
Posted by Ryan Bloom <rb...@ntrnet.net>.
On Mon, 30 Sep 2002, Greg Stein wrote:
> On Mon, Sep 30, 2002 at 06:53:09PM -0400, Ryan Bloom wrote:
> >...
> > The problem is that the default_handler shouldn't be involved. Because
> > mod_dav is now replacing the r->handler field for ALL requests, things
>
> Woah! *NOT* "all" requests. Only those under the URL namespace which has
> been assigned to mod_dav. It does not just go out and blast r->handler
> willy-nilly. You have specifically enabled DAV for the URL space in
> question.
>
> >...
> > If those two things are done, then we could have two handlers for the same
> > resource. However, mod_dav shouldn't just be taking over all requests and
> > assuming that they were meant for the core server. Doing so means that
> > all generators are broken if DAV is loaded in the server.
>
> It does not "just be taking over all requests." It is handling requests for
> the space that you've assigned to mod_dav.
>
> 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.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------
Re: POST
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Sep 30, 2002 at 06:53:09PM -0400, Ryan Bloom wrote:
>...
> The problem is that the default_handler shouldn't be involved. Because
> mod_dav is now replacing the r->handler field for ALL requests, things
Woah! *NOT* "all" requests. Only those under the URL namespace which has
been assigned to mod_dav. It does not just go out and blast r->handler
willy-nilly. You have specifically enabled DAV for the URL space in
question.
>...
> If those two things are done, then we could have two handlers for the same
> resource. However, mod_dav shouldn't just be taking over all requests and
> assuming that they were meant for the core server. Doing so means that
> all generators are broken if DAV is loaded in the server.
It does not "just be taking over all requests." It is handling requests for
the space that you've assigned to mod_dav.
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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: POST
Posted by Ryan Bloom <rb...@ntrnet.net>.
On Mon, 30 Sep 2002, Greg Stein wrote:
> On Mon, Sep 30, 2002 at 09:36:50AM -0400, rbb@apache.org wrote:
> > On Sun, 29 Sep 2002, Justin Erenkrantz wrote:
> >
> > > On Mon, Sep 30, 2002 at 01:17:55AM -0400, Ryan Bloom wrote:
> > > > Because 2.0.42 always displays script source for CGI scripts that use
> > > > POST, I believe that we should put that notice on our main site, and stop
> > > > suggesting 2.0.42 for production use.
> > >
> > > I could not reproduce your problem in my tests. Do you have a clear
> > > reproduction case? (POSTing to a DAV resource for me yields a 404.)
> > >
> > > Is it somehow related to mounting a DAV repository at / and the
> > > server getting confused about the /cgi-bin/ dir? -- justin
> >
> > Nope, any script that is under DAV control will post the source to the
> > user.
>
> Hunh?
>
> The POST code in mod_dav checks for DAV locks on the resource (per RFC
> 2518). If there is a lock, then it returns an appropriate error. Otherwise,
> it just returns DECLINED and lets (presumably) the default handler deal with
> the POST request.
>
> The bug is located in server/core.c::default_handler(). It serves up the
> content of a file that you POST to. That isn't right.
>
> Of course, we also have the problem that we can't have more than one
> handler. We could restore the RFC 2518 POST check by putting that into a
> different processing phase. Not sure which, tho... (it needs to be after the
> authentication, at least)
The problem is that the default_handler shouldn't be involved. Because
mod_dav is now replacing the r->handler field for ALL requests, things
broke. Basically, mod_cgi had been set as the handler, but the mod_dav
came in and took over. Then, when mod_dav was done, it passed the request
over to the core server, which shouldn't be seeing this request. If
mod_dav is going to take over all reqeusts, then it needs to save a copy
of the old r->handler field so that it can be reset appropriately, and it
needs to be registered as APR_HOOK_REALLY_FIRST for the handler phase.
If those two things are done, then we could have two handlers for the same
resource. However, mod_dav shouldn't just be taking over all requests and
assuming that they were meant for the core server. Doing so means that
all generators are broken if DAV is loaded in the server.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------