|
The cause of these tends to be related to browsers that do predictive web requests to the server. The 408 happens after the unused connections time-out. The issue is also tied to RHEL 6.x and CentOS 6.x systems after a certain kernel version, I can’t remember which one off the top of my head. I haven’t heard of any ability to stop this from happening, assuming you’re running a public web server and have no control over the browser settings. If you really care, the only workaround I’m aware of is to configure an apache timeout on empty requests to make them time out quicker. This is currently what
I’m doing. LoadModule reqtimeout_module modules/mod_reqtimeout.so <IfModule reqtimeout_module> RequestReadTimeout header=2-10,MinRate=500 body=20-120,MinRate=1000 </IfModule> YMMV -Tony From:
박원석 [mailto:jjomacson@xxxxxxxxx]
I sent this mail to
users@xxxxxxxxxxxxxxxx but at 06 JAN, but i can't find that mail in mailing list
so i send to mail again, < --original contents-- > Hello, I send this mail at first time and I had some questions with this enviroment ======================================== - Usage : Image Server(there is no backend system) - Old one : RHEL5.x, httpd-2.2.17 - New one : RHEL6.x, httpd-2.2.22 - WEB configuration : old and new one same configuration - OS parameter : limits.conf, security.conf are same thing ======================================== httpd-default.conf Timeout 15 KeepAlive Off ======================================== httpd-mpm.conf <IfModule mpm_worker_module> ========================================== the problem is that the new one(2.2.22) have the 408 status code in accesslog 183.113.39.228 - - [01/Jan/2014:08:30:11 +0900] "-" 408 - 0 and the count of 408 is like this [root@POSTIMG6 logs]# grep " 408 " access.20131001.log | wc -l 48 [root@POSTIMG6 logs]# more access.20131001.log | wc -l 10148069 [root@POSTIMG6 logs]# grep " 408 " access.20131002.log | wc -l 40 [root@POSTIMG6 logs]# grep " 408 " access.20131003.log | wc -l 66 [root@POSTIMG6 logs]# grep " 408 " access.20131004.log | wc -l 77 [root@POSTIMG6 logs]# grep " 408 " access.20131005.log | wc -l 64 [root@POSTIMG6 logs]# grep " 408 " access.20131006.log | wc -l 53 [root@POSTIMG6 logs]# grep " 408 " access.20131101.log | wc -l 1013 [root@POSTIMG6 logs]# grep " 408 " access.20131115.log | wc -l 2145 [root@POSTIMG6 logs]# grep " 408 " access.20131130.log | wc -l 1668 [root@POSTIMG6 logs]# grep " 408 " access.20131215.log | wc -l 2859 [root@POSTIMG6 logs]# grep " 408 " access.20131216.log | wc -l 3453 [root@POSTIMG6 logs]# grep " 408 " access.20131217.log | wc -l 1747 [root@POSTIMG6 logs]# grep " 408 " access.20131218.log | wc -l 4008 [root@POSTIMG6 logs]# grep " 408 " access.20131219.log | wc -l 7000 [root@POSTIMG6 logs]# grep " 408 " access.20131220.log | wc -l 23146 [root@POSTIMG6 logs]# grep " 408 " access.20131221.log | wc -l 9503 [root@POSTIMG6 logs]# grep " 408 " access.20131222.log | wc -l 101 [root@POSTIMG6 logs]# grep " 408 " access.20131223.log | wc -l 20689 [root@POSTIMG6 logs]# more access.20131223.log | wc -l 14209497 [root@POSTIMG6 logs]# grep " 408 " access.20131224.log | wc -l 10163 [root@POSTIMG6 logs]# grep " 408 " access.20131230.log | wc -l 10946 I search the code of 408 and there are some reasons like this - the leak of the apache timeout value - ddos attacks and etc but I thinks there is not matching above reasons because the old one is not a problem and L4 above the web servers is balancing to the old and new servers in no issues. I fine some changes between 2.2.17 and 2.2.18 I want to know that the mean of chanelog at 2.2.18 and it will be the reason the 408 status codes. =========================================================== Changes with Apache 2.2.18 =========================================================== I understood this substance that if it is no keepalive timeout in apache, all request is return the 408 code. but all of the request are not a return 408 code.
my Questions? 1) which case the code of 408 is mainly cause?? 2) what is the meaning of this changes(in 2.2.18) of the sentence?
thanks a lot!! |
|