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
