Date: Sat, 1 Feb 1997 20:35:59 -0700 (MST)
From: Marc Slemko <marcs@znep.com>
To: new-httpd@hyperreal.com
Subject: Re: lingering_close
In-Reply-To: <199702020204.VAA11029@shado.jaguNET.com>
Message-ID: <Pine.BSF.3.95.970201202338.331O-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 Sat, 1 Feb 1997, Jim Jagielski wrote:

> Marc Slemko wrote:
> > 
> > >  o That as long as there are no problem or hiccups during PUTS
> > >    or persisticonns (my word :) ) l_c() did absolutely nothing
> > >    and so there was no difference between having it and not
> > 
> > Incorrect.  There are normal cases during the operation of persistent
> > connections where the server wants to close the connection.  One example 
> > is a server timeout.
> 
> If there server timesouts, it means that it either hasn't rec'd any
> data in awhile, or else it has listened to the maximum persiticonns
> that it wants. In the first case, there's no data to read. In the
> 2nd it doesn't seem to make sense to me that the server must
> contibue listening to requests just to ignore them... Maybe I'm
> missing the point though, it certainly wouldn't be the 1st time :)

You also have to remember the (normally) very short keepalive timeout.

The server has to keep listening until it knows the client has all the
data, ie. the FIN which signals a close to the client application.  That
is what lingering_close() does. It is fine to say it shouldn't have to,
but this is a very low level protocol issue and I have seen no other
solution.  As I said before, there is no way for the client to figure out
what the RST it would get without lingering_close() means so it
essentially _has_ to treat it as an error. 

> 
> > Another is any type of request for which it
> > can't handle persistent connections such as any HTTP/1.0 keepalive
> > request which doesn't have a content-length, such as SSIs).  _ANY_
> > time the server closes the persistent connection this possibility
> > is there simply because the client expects the connection to be
> > there.
> 
> Shouldn't the client check? Or do clients assume infinite numbers
> of persisticonns?

The client CAN'T check on the situations that are the problem except by
trying it.  If the server shuts down the connection and the client gets
the FIN before trying to send anything, everything is fine.

There is no way to know for sure that the server has not shutdown the
connection at the time you send data due to the simple fact that there is
a RTT.  There is no negotation of the number of requests per connection
between the client and server.  (well, there is in the 1.0 Keep-Alive
hack, but I don't see why the client should have to care especially since 
it wouldn't really solve much).  Even though there is a header that says
"close the connection after this is sent", that doesn't solve the problem
due to pipelining and timeouts.

> 
> > Before this was a much simpler problem because the client
> > wouldn't be sending any more data anyway.  With persistent connections,
> > it can.  If it doesn't get a response to a request, it should resend
> > it in another connection, no problems.  If it gets an error, however,
> > it should whine.
> 
> 
> -- 
> ====================================================================
>       Jim Jagielski            |       jaguNET Access Services
>      jim@jaguNET.com           |       http://www.jaguNET.com/
>                   "Not the Craw... the CRAW!"
>