www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Blacklock <dblackl...@pirus.com>
Subject protocol/6492: HTTP 1.1 connections not removed after receipt of TCP reset.
Date Tue, 05 Sep 2000 13:54:31 GMT

>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:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Tue Sep 05 07:00:01 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     dblacklock@pirus.com
>Release:        1.3.9
>Organization:
apache
>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:
>Unformatted:
 [In order for any reply to be added to the PR database, you need]
 [to include <apbugs@Apache.Org> 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!     ]
 
 


Mime
View raw message