httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: cvs commit: httpd-2.0/modules/http http_request.c
Date Fri, 21 Jun 2002 00:21:48 GMT
On Thu, Jun 20, 2002 at 05:30:52PM -0400, Greg Ames wrote:
> No sir.  That's just one way to cause recursive errors.  The code in ap_die that
> detects and prevents infinite recursive errors was written for a reason.  If we
> cripple it, Apache becomes less robust.

No, this isn't stopping all recursive errors - it's stopping a
certain class of errors that are at the heart of the protocol
dealing with user input.  Recursive errors still work, but only for
ones that are internal to the server.  Any error that deals with
the invalidity of the client request shouldn't be recursive (that
means we're parsing it twice).

The 400 from mod_rewrite is wrong in any case - the resource is
not found or it is a misconfiguration in the server rules.  A 400
should only be for syntactical protocol errors.  There is nothing
invalid in the request that was sent to mod_rewrite - other than
the fact that it could not find the resource.  I believe that is a
404 (which doesn't drop the connection).

> We ought to be able to have our cake and eat it too.  It is easy to turn off
> keepalives based on the original "type" passed to ap_die.  I think you're saying
> there's now a dependency that r->status matches the original "type" on exit,
> right?

Only where ap_status_drops_connection is true.  The problem before
was that if you got a 404 and then got a 413 on the discard, it
would revert the status to a 404 and then try to read the body as
part of the handlers in serving the error page.

We simply can not do that - so the status can't be 404 when we get a
413 - it must be a 413.  When we are supposed to drop the connection,
r->status *must* indicate that.  -- justin

View raw message