1 Reply Latest reply on Apr 13, 2011 5:59 AM by Jean-Frederic Clere

    Misbehaving client causes worker to go bad

    Alexey Syomichev Newbie

      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