Received: (qmail 58985 invoked by uid 501); 5 Sep 2000 13:54:31 -0000 Message-Id: <20000905135431.58983.qmail@locus.apache.org> Date: 5 Sep 2000 13:54:31 -0000 From: Dave Blacklock Reply-To: dblacklock@pirus.com To: submit@bugz.apache.org Subject: HTTP 1.1 connections not removed after receipt of TCP reset. X-Send-Pr-Version: 3.110 >Number: 6492 >Category: protocol >Synopsis: HTTP 1.1 connections not removed after receipt of TCP reset. >Confidential: no >Severity: serious >Priority: medium >Responsible: apache >State: closed >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Tue Sep 05 07:00:01 PDT 2000 >Closed-Date: Tue Sep 05 08:56:03 PDT 2000 >Last-Modified: Tue Sep 05 08:56:03 PDT 2000 >Originator: dblacklock@pirus.com >Release: 1.3.9 >Organization: >Environment: Red Hat Linux 2.2.13-0.13smp in a Dell 1300 server with 1 processor. But, this problem may not be platform specific. >Description: When a client sends "x" number of HTTP 1.1 GETs and then finishes its use of the connection(s), instead of performing a normal HTTP close session with the server to close all open HTTP 1.1 connection(s), it issues a TCP reset. PROBLEM: After the reset, the apache server tries several times to close the connection by sending an ACK and FIN with the ACK number pointing to the old connection that shouldn't exist anymore because of the TCP Reset. When the client then tries to reopen the connection using the same MAC and IP address used in the original connection, by sending its SYN, the server responds with just its ACK ( the server's SYN = 0 ) and the ACK number still points back to the old connection that should have been closed upon receipt of the TCP Reset. The result is that the client's attempt to reopen the same connection fails. To allow the client to continue to work with the server, I have to manually stop and start the apache server. >How-To-Repeat: Not sure. This client exists on a specific hardware test platform. I can ask the supplier if I can use their name and product info if you need this information. >Fix: I would suggest reviewing how TCP Resets are handled in your code. Hopefully, with the information provided here, you will be able to confirm this behavior without actually reproducing the issue with hardware. If you think you know what might be causing this problem, I will be happy to try any potential beta fix you can think of against this platform. Thanks, >Release-Note: >Audit-Trail: State-Changed-From-To: open-closed State-Changed-By: marc State-Changed-When: Tue Sep 5 08:56:03 PDT 2000 State-Changed-Why: Apache has no control over how the OS handles this. It is one reason why clients need to properly close their connections, and is a reason why clients that are silly enough to try to work around how TCP functions need to be smart enough to not just reuse the same port on the client side. I can't say exactly what is going on here, but it really doesn't matter: either the connection shouldn't be aborted based on what the client is doing, or it should be but the OS is buggy. We can't do anything in either case. >Unformatted: [In order for any reply to be added to the PR database, you need] [to include in the Cc line and make sure the] [subject line starts with the report component and number, with ] [or without any 'Re:' prefixes (such as "general/1098:" or ] ["Re: general/1098:"). If the subject doesn't match this ] [pattern, your message will be misfiled and ignored. The ] ["apbugs" address is not added to the Cc line of messages from ] [the database automatically because of the potential for mail ] [loops. If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request from a ] [developer. Reply only with text; DO NOT SEND ATTACHMENTS! ]