Looked OK at the beginning but after 3 days in use this solution seems to have made things worse. The number of 408 responses has gone up fast and I don't know why. As suggested I added the following line:
RequestReadTimeout header=10 body=30 with the example timeouts taken from the Apache documentation. There is no indication in the docs as to what the default is and 10 seconds seems long in view of the fact that we often get several 408's from the same IP per second according to the log. My analysis is that this should not be a problem because the request and the data content are passed in the URL (method=GET) so as soon as the server has the request it has the body too. This is HTTPS but I don't think renegotiation (which adds to the timeout) would be required because the service is already, from our viewpoint, running. These are background (AJAX) requests and are usually issued within a few seconds to a minute following each other. The documentation is somewhat vague on how to chose an appropriate value and how to debug. Any help appreciated! Regards, John ====================================== On Sunday 20 May 2012 14:46:12 you wrote: > On Tuesday 15 May 2012 14:29:56 Jeroen Geilman wrote: > > On 05/11/2012 06:01 PM, John Iliffe wrote: > > > I recently switched from Apache-2.2.14 to Apache-2.4.2. In the > > > entire time we ran 2.2.14 I don't recall seeing a response code > > > 408. Since we switched two weeks ago we average about 30 - 35 a > > > day. Our server is not heavily loaded. > > > > > > The RFC definition of response code 408 is "Request Timeout, the > > > client did not produce a request within the time the server was > > > prepared to wait." > > > > > > All of these 408's are arising from background (AJAX) requests in > > > the browser that are well known to be very short (16 bytes of data > > > coded as an HTTP GET). > > > > > > Which parameter have I set to short? Looking at the Apache docs > > > there don't seem to be any obvious choices. > > > > As clearly documented, one of the many new modules in 2.4 is > > mod_reqtimeout, which controls exactly this. > > > > http://httpd.apache.org/docs/2.4/mod/mod_reqtimeout.html > > > > It allows the server administrator to determine on a per-vhost basis > > how long the request timeout should be, and what the minimum data > > rate should be. > > This was added specifically to combat bots and slowdos attempts. > > > > The defaults - which you did not adjust for your site - are obviously > > not suited for your small AJAX snippets. > > > > Blind upgrades never go well. > > Sorry for the delay; wanted to be sure I would be here if something > screwed up! > > This was NOT a blind update; just a sysadmin with limited Apache > experience. My job is to maintain and operate the web servers for a > small company, including sysop and LAN duties and web designer, so I > have limited speciality with most of the programmes that are running on > the server. > > That said, I have over the years (I've been in IT since 1966 and am now > "retired") developed a high degree of confidence in the developers of > OSS and their ability to set reasonable defaults. When I upgraded to > Apache 2.4 I did catch one unknown bug: won't run with PHP 5.4.x - all > child processes segfault when called (which is probably fixed by now) > and one questionable documentation - "order allow deny" which has been > syntactically changed but still in the 2.4 docs the old way. > > So, yes I did read the documentation and attempt to understand it. > mod_reqtimeout and its parameters arrived with Apache 2.2.15 and is not > documented in the 2.4 migration either, so yes, maybe I did miss > something but it sure isn't obvious! > > Thanks for the response and so far seems to have resolved the problem. > > Regards, > > John --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
