Justin Erenkrantz wrote:
> 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.
OK, let's turn that around. Suppose we got a 413 first and then a 404. Which
one should we believe? And how should our canned error message read in both
cases?
We ought to be able to display both in the correct order in our canned error
message, no matter which happens first. And it sounds like if *either* status
wants to drop the connection, we should avoid reading the body. Since ap_die
now resets r->connection->keepalive anytime ap_status_drops_connection is true
for the input status, I think this change to
ap_discard_request_body would work:
--- modules/http/http_protocol.c 19 Jun 2002 18:43:28 -0000 1.440
+++ modules/http/http_protocol.c 21 Jun 2002 19:41:00 -0000
@@ -1882,7 +1882,7 @@
*
* This function is also a no-op on a subrequest.
*/
- if (r->main || ap_status_drops_connection(r->status)) {
+ if (r->main || !r->connection->keepalive) {
return OK;
}
Greg
