httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: PHP POST handling (was: cvs commit: httpd-2.0/server core.c)
Date Tue, 01 Oct 2002 17:34:20 GMT
On Tue, 1 Oct 2002, Greg Stein wrote:

> On Tue, Oct 01, 2002 at 12:29:53PM -0400, wrote:
> > On 1 Oct 2002 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 Bloom               
550 Jean St
Oakland CA 94610

View raw message