The subject is misleading; we do allow keepalives on any bogus
requests, today. Undoubtedly this is already used in the wild.
Attached is a patch that would drop keepalive for the garbage
requests that never even hit mod_forensics, or any other module,
due to bogus request lines or unparseable header fields.
The argument against, more cycles are wasted in setup and
teardown than simply filtering bogus requests. Counter arguments,
so does the client; and the bogus connection is dumped and a fresh
one created. This actually solved many issues with mod_ssl on
Win32, although it was entirely the wrong solution to the issue
I discovered.
FYI yes in spite of ap_set_keepalive() they still are active. It's
as simple as the fact that the previous request on the connection
is successful, therefore keepalives are alive and well.
Anyways, comments on the patch?
Bill
Index: src/main/http_protocol.c
===================================================================
--- src/main/http_protocol.c (revision 169530)
+++ src/main/http_protocol.c (working copy)
@@ -1186,6 +1186,7 @@
ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, r,
"request failed: URI too long");
+ r->keepalive = 0;
ap_send_error_response(r, 0);
ap_log_transaction(r);
return r;
@@ -1194,6 +1195,7 @@
ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, r,
"request failed: erroneous characters after protocol
string: %s",
ap_escape_logitem(r->pool, r->the_request));
+ r->keepalive = 0;
ap_send_error_response(r, 0);
ap_log_transaction(r);
return r;
@@ -1207,6 +1209,7 @@
if (r->status != HTTP_REQUEST_TIME_OUT) {
ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, r,
"request failed: error reading the headers");
+ r->keepalive = 0;
ap_send_error_response(r, 0);
ap_log_transaction(r);
return r;
@@ -1260,6 +1263,7 @@
"(see RFC2616 section 14.23): %s", r->uri);
}
if (r->status != HTTP_OK) {
+ r->keepalive = 0;
ap_send_error_response(r, 0);
ap_log_transaction(r);
return r;
