> -----Ursprüngliche Nachricht----- > Von: Nick Kew
[..cut..]
>
>
> That's the same bug and fix as PR#37790!
>
> Which leads me to wonder, is there some good reason not to
> insert the input filter unconditionally somewhere earlier in
> request_post_read? As it stands, it looks as if your fix has
> the same problem as mine: namely, it fixes the immediate
> problem but leaves the bug waiting to manifest itself anew in
> other early error conditions.
What about the following patch instead (currently untested)?
Index: server/protocol.c
===================================================================
--- server/protocol.c (revision 370457)
+++ server/protocol.c (working copy)
@@ -902,6 +902,9 @@
"(see RFC2616 section 14.23): %s", r->uri);
}
+ ap_add_input_filter_handle(ap_http_input_filter_handle,
+ NULL, r, r->connection);
+
if (r->status != HTTP_OK) {
ap_send_error_response(r, 0);
ap_update_child_status(conn->sbh, SERVER_BUSY_LOG, r);
@@ -910,8 +913,6 @@
}
if ((access_status = ap_run_post_read_request(r))) {
- ap_add_input_filter_handle(ap_http_input_filter_handle,
- NULL, r, r->connection);
ap_die(access_status, r);
ap_update_child_status(conn->sbh, SERVER_BUSY_LOG, r);
ap_run_log_transaction(r);
@@ -934,8 +935,6 @@
ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
"client sent an unrecognized expectation value of "
"Expect: %s", expect);
- ap_add_input_filter_handle(ap_http_input_filter_handle,
- NULL, r, r->connection);
ap_send_error_response(r, 0);
ap_update_child_status(conn->sbh, SERVER_BUSY_LOG, r);
ap_run_log_transaction(r);
@@ -943,8 +942,6 @@
}
}
- ap_add_input_filter_handle(ap_http_input_filter_handle,
- NULL, r, r->connection);
return r;
}
Regards
Rüdiger
add_input_filter.diff
Description: add_input_filter.diff
