Misbehaving client causes worker to go bad
In addition to the AJP header read timeout discussed in one of the neighbouring threads, I came across a timeout due to poor client behavior, having a similar overly disruptive effect on the overall status of the worker. This timeout occurs when a client sends an HTTP header with non-zero content length attribute, but stops sending any data just after the header. The code responsible for this is in mod_proxy_ajp.c:
/* Get client provided Content-Length header */
content_length = get_content_length(r);
status = ap_get_brigade(r->input_filters, input_brigade,
AP_MODE_READBYTES, APR_BLOCK_READ,
maxsize - AJP_HEADER_SZ);
if (status != APR_SUCCESS) {
/* We had a failure: Close connection to backend */
conn->close++;
ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, r->server,
"proxy: ap_get_brigade failed");
apr_brigade_destroy(input_brigade);
return HTTP_INTERNAL_SERVER_ERROR;
}
Similar to the other case I mentioned, returning HTTP_INTERNAL_SERVER_ERROR leads to a change in overall worker state to NOTOK until the next STATUS message restores it. Until then the whole perfectly healthy worker is not considered for routing and it may result in 503 responses if no other alternatives are available.
This can be reproduced by telnetting into the http endpoint, sending an HTTP header like this (with an extra empty line in the end), and waiting for 5 minutes (where is this timeout configured?):
POST /sleep/sleep.jsp?SLEEP_TIME=350000 HTTP/1.1
Host: hostname.foo.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://hostname.foo.com/sleep/sleep.jsp
Content-Type: multipart/form-data; boundary=---------------------------287032381131322
Content-Length: 432
In mod_proxy_ajp.c of the standard httpd 2.2.15 distribution the return code is different (HTTP_BAD_REQUEST), which seems to reflect the nature of the error better (this is a client-side problem, not a server issue after all). Would it make sense to change the return code in mod_cluster's version of mod_proxy_ajp.c to HTTP_BAD_REQUEST ?
Thank you,
--Alexey
