DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14443>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14443 Keep-Alive randomly causes TCP RSTs Summary: Keep-Alive randomly causes TCP RSTs Product: Apache httpd-1.3 Version: 1.3.27 Platform: PC OS/Version: FreeBSD Status: NEW Severity: Major Priority: Other Component: core AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] I am running Apache 1.3.27 with PHP 4.2.3 as a DSO. OS is FreeBSD 4.6-RELEASE. kerafyrm:[~] /usr/local/sbin/httpd -l Compiled-in modules: http_core.c mod_so.c suexec: disabled; invalid wrapper /usr/local/sbin/suexec I am running some PHP scripts, which do nothing exceptionnal, serve dynamic content out of a database, using persistant MySQL and PgSQL connections. I am not sure whether this is relevant to the problem. Very randomly, and quite rarely, the following thing happens. - From the user's point of view: User clicks on a link, a blank screen comes up in IE, very quickly after the click (obviously quicker than it would take to make the HTTP request, fetch any data, etc). User reloads the page, and most of the time the page is served correctly after that. - From my point of view: I have pulled most of my hair out looking for the source of the problem. o httpd processes do not crash when it happens (i.e. PID numbers are the same as before the click). o I have disabled the PHP accelerator from IonCube I have been using to cache PHP bytecode, thinking that it might cause the error. The error still happened afterwards. o I have disabled the Keepalive option for this virtual host, and this took away the problem. It used to happen about once per hour of development work, now it never happens. I don't really care about KeepAlive, but find it strange for this incident to happen. o I have caught the error in a tcpdump ! :-) Here is the output: Here we see the data being transferred from the server to the client. A page is fetched properly. 14:19:27.584271 server.http > client.1111: . 50446:51906(1460) ack 3672 win 58400 (DF) (ttl 64, id 13211, len 1500) 14:19:27.584322 server.http > client.1111: . 51906:53366(1460) ack 3672 win 58400 (DF) (ttl 64, id 13212, len 1500) 14:19:27.584353 server.http > client.1111: P 53366:53443(77) ack 3672 win 58400 (DF) (ttl 64, id 13213, len 117) 14:19:27.588440 client.1111 > server.http: . [tcp sum ok] 3672:3672(0) ack 51906 win 17520 (DF) (ttl 128, id 4715, len 40) 14:19:27.588541 client.1111 > server.http: . [tcp sum ok] 3672:3672(0) ack 53443 win 17520 (DF) (ttl 128, id 4716, len 40) 14:19:27.589136 server.http > client.1111: P [tcp sum ok] 53443:53444(1) ack 3672 win 58400 (DF) (ttl 64, id 13216, len 41) 14:19:27.767144 client.1111 > server.http: . [tcp sum ok] 3672:3672(0) ack 53444 win 17519 (DF) (ttl 128, id 4717, len 40) End of transfer, httpd keeps the socket alive. A few seconds later, httpd decides it's time to close this socket. 14:19:37.490342 server.http > client.1112: F [tcp sum ok] 4963:4963(0) ack 419 win 58400 (DF) (ttl 64, id 13268, len 40) 14:19:37.490658 client.1112 > server.http: . [tcp sum ok] 419:419(0) ack 4964 win 17520 (DF) (ttl 128, id 4718, len 40) 14:19:37.588810 client.1112 > server.http: R [tcp sum ok] 1951078694:1951078694 (0) win 0 (DF) (ttl 128, id 4719, len 40) 14:19:44.559592 server.http > client.1111: F [tcp sum ok] 53444:53444(0) ack 3672 win 58400 (DF) (ttl 64, id 13474, len 40) 14:19:44.559906 client.1111 > server.http: . [tcp sum ok] 3672:3672(0) ack 53445 win 17519 (DF) (ttl 128, id 4720, len 40) A few more seconds later, the client requests a page from the server again, but only to be greeted with a RST ;-( 14:20:03.556040 client.1111 > server.http: P 3672:4075(403) ack 53445 win 17519 (DF) (ttl 128, id 4722, len 443) 14:20:03.556210 server.http > client.1111: R [tcp sum ok] 2298357875:2298357875 (0) win 0 (ttl 64, id 13832, len 40) End of tcpdump snippet. The client is a Win 2k workstation running IE6. Is this a bug in Win2k TCP stack? In IE? In Apache? The client and the server are both on separate networks, with a tunnel between them. The client is also ip-masqueraded by a Linux 2.4 box. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
