httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: lingering_close
Date Sat, 01 Feb 1997 22:27:08 GMT
On Sat, 1 Feb 1997, Jim Jagielski wrote:

> Marc Slemko wrote:
> > 
> > Because Roy brought up the "real" reason for lingering_close, as discussed
> > by him with rst and others.  This reason makes sense and tests have shown
> > that there _are_ cases where clients have problems with PUTs and
> > persistent connections without lingering_close().
> > 
> (I know, I promised to be quiet but... :) )
> Shouldn't that be: There are cases where buggy clients may have
> problems when there are problems during PUTS and persistant
> connections". I always thought:

No.  I have posted several times about the situations where problems can
happen even with no "problems".

>  o That clients that do their job well would avoid Apache
>    (or any server) needing l_c(). This includes such things
>    as checking that authorization was approved before sending
>    data

No.  There is no way to check that authorization is accepted, only that
the client didn't get anything back before it sent the body; in any
case, that breaks because some servers don't send anything until
they get all the data from the client.  The client can not tell a
"this connection was just closed" RST apart from a "some other error
happened" RST.  If they get the first type of RST, they could skip reporting
it and just retry.  If they got the second, however, it should be an 

Changing this requires modifying all the server and client TCP stacks as 
well as most or all of the APIs.  It is actually implemented on a small
scale now on some systems, but nothing useful.

>  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.  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.  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.

>  o If there are problems, l_c() simply allows Apache to gobble
>    up all incoming data (and let the client finish sending
>    sending) before the final TCP closeout. Since the first thing
>    l_c() does is close all output, we can't send any error message
>    or anything... We just wait until we get all the data (or after
>    a period of time) and then shutdown (totally) the socket.
>    This assures (well, that's too strong) that the client knows
>    that gets the notification that the socket is dead when it's
>    "able" to handle it (unless, of course, the timeout kicks
>    in, in which case you are back to l_c() not doing anything
>    of "value" since you are still closing the socket before
>    all the sent data is rec'd - in effect, l_c() is of value
>    iff the remaining data is rec'd before the timeout kicks
>    in, which is totally dependent on the amount of data
>    and the length of the timeout, of which Apache has control
>    only over the timeout length -*whew*)

View raw message