On Monday 28 September 2009, Dan Poirier wrote:
> Is there some good reason not to log the 408's in this case?
I am +1 for logging the 408's. I also think in case of a timeout, 408
should be logged instead of 400. The attached patch does that.
--- protocol.c.orig 2009-09-05 00:36:31.448689825 +0200
+++ protocol.c 2009-09-05 00:35:43.472690365 +0200
@@ -691,7 +691,12 @@
&len, r, 0, bb);
if (rv != APR_SUCCESS) {
- r->status = HTTP_BAD_REQUEST;
+ if (rv == APR_TIMEUP) {
+ r->status = HTTP_REQUEST_TIME_OUT;
+ }
+ else {
+ r->status = HTTP_BAD_REQUEST;
+ }
/* ap_rgetline returns APR_ENOSPC if it fills up the buffer before
* finding the end-of-line. This is only going to happen if it
@@ -877,7 +882,7 @@
r->read_length = 0;
r->read_body = REQUEST_NO_BODY;
- r->status = HTTP_REQUEST_TIME_OUT; /* Until we get a request */
+ r->status = HTTP_OK; /* Until further notice */
r->the_request = NULL;
/* Begin by presuming any module can make its own path_info assumptions,
@@ -916,7 +921,7 @@
if (!r->assbackwards) {
ap_get_mime_headers_core(r, tmp_bb);
- if (r->status != HTTP_REQUEST_TIME_OUT) {
+ if (r->status != HTTP_OK) {
ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
"request failed: error reading the headers");
ap_send_error_response(r, 0);
@@ -957,8 +962,6 @@
apr_brigade_destroy(tmp_bb);
- r->status = HTTP_OK; /* Until further notice. */
-
/* update what we think the virtual host is based on the headers we've
* now read. may update status.
*/
