Date: Tue, 21 Jan 1997 22:04:01 -0700 (MST)
From: Marc Slemko <marcs@znep.com>
To: new-httpd@hyperreal.com
Subject: Re: lingering_close
In-Reply-To: <199701220444.XAA12829@shado.jaguNET.com>
Message-ID: <Pine.BSF.3.95.970121215226.12598N-100000@alive.ampr.ab.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@hyperreal.com

On Tue, 21 Jan 1997, Jim Jagielski wrote:

> Marc Slemko wrote:
> > 
> > 
> > The whole point of needing lingering_close() is that we have to keep
> > taking data until the client acknowledges that it has gotten all the data
> > we sent it.
> > 
> 
> I'm not sure if that's right. I though the whole idea was that
> some clients continued sending data even if we've already slammed
> the door shut. Like a door-to-door Fuller Brush salesman at your
> door still talking and doing his pitch on your porch long
> after you've closed the door. Instead, we keep the door open
> and listen to his pitch twiddling our thumbs until he says
> "I'm done" and we say "no thanks" and then slam the door.

If a client is sending data at the time we close a connection, if we fully
close it then the next packet of data we get will cause us to send a RST
to them, destroying the connection and any data that hasn't been processed
on their end yet.  This can happen when a client is PUTting data and we
have something like an authorization error that we spit out before they
even finish putting the data (this one could be worked around by not
sending the error until after they sent all the data, but that isn't
overly nice to implement in the current code base) _or_ when we are doing
persistent (ie. keepalive) connections.  If the server times out and
decides to close the connection, but before the FIN gets to the client the
client starts sending a new request, the response to that request will be
a RST which will cause an error on the client.  

In both those cases (and in the SVR4 bug) we need to be sure we don't send
a RST to mess up the connection before the client has everything we sent,
so we have to wait until we know they have it.  The problem is that we can
keep getting data after we slam the door, the solution is that we need to
be sure the client has got everything.  Once the client has closed their
end (ie. acknowledged that they have all the data) we don't care any more.

> 
> We also can stop accepting data after some "timeout" period

Yes.  But this would have to be somewhere in the order of several minutes
I think.

> as well; we don't need to listen to all of it I think. Some
> sort of delay before the close would be helpful and would
> seem to be all that's required to allow the client to
> get it's affairs in order and handle the RST. 
> 
> Maybe a happy medium would be:
> 
> 	shutdown output end on server
> 	read some data, but not all (4k or so)
> 	slam it shut

No.  Consider the case where both ends are behind a congested link with a
1000ms total RTT but half-decent bandwidth.  We can read a lot more than
4k in one RTT.