httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: several messages
Date Sat, 01 Feb 1997 22:05:50 GMT
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:

 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

 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

 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*)

      Jim Jagielski            |       jaguNET Access Services           |
                  "Not the Craw... the CRAW!"

View raw message