Re: lingering_close()

[Randy Terbush <ra...@zyzzyva.com>]

> Ok, I can replicate the problem now.  Happens if I don't use
> lingering_close, doesn't if I do.  
> 
> Boy is Navigator Gold lame.  This is the first time I have used it and... 
> well... lame.  It shows my password for an instant in the status line at
> the bottom when I'm doing a PUT upload.  Sheesh.  Well, I suppose I should
> be happy that it can't be much worse than FrontPage (server side) for
> security... 
> 
> Now the trick is a fix.  Hopefully not too hard.  Aha.  I think the
> problem is that as soon as Apache gets an invalid authorization, it sends
> out a whine message and closes the connection.  However, Netscape is still
> sending the file at the same time.  As soon as Apache finishes sending it,
> it closes the connection.  Netscape is still trying to write, so it whines
> when the connection is closed.
> 
> lingering_close() gets around this by slurping up and throwing away the
> data that Netscape sends.  
> 
> I have no clue about PUT and how that stuff is supposed to work, so I will
> have to check the RFC.  I'm cc:ing this to the list so anyone who has some
> comments on how the server should handle the above situation can enlighten
> me.  Should the server just slurp up all input coming from the client if
> it needs to generate an error?  Could be a Netscape bug. 

Funny, this is beginning to sound familiar. :)  As I remember,
Dirk VanGuilik has looked at this some as well. You might grep
through the archives for PUT. It all comes back to me that this 
is the reason that RST added lingering_close(). Whether or not
there is another way is the question.

I'm out for the night...


> On Mon, 20 Jan 1997, Randy Terbush wrote:
> 
> > 
> > Did you find that email in the archive where a 1.1.1 user solved
> > a problem he was having with PUT by including the lingering_close()
> > code?
> > 
> > That triggers another memory for me. It was RST who wrote the
> > lingering_close() code. It would have probably been included about
> > the same time he was looking into improving PUT support. Makes sense
> > that we need to still allow received data to trickle in on a PUT.
> > 
> > Something to think about as we test this...
> > 
> > 
> > 

Re: lingering_close()

[Marc Slemko <ma...@znep.com>]

Aha.  96/02 I think I can find the first mention of SO_LINGER from someone
having trouble with outbound data not completing.  After that I can
find no discussion of it WRT PUT, and looked at all the messages Dirk
sent back to 96/04 without finding anything on the topic.  I also
looked for stuff on PUT, but it is too darn hard to miss it if it is
lowercase...  From everything I saw, lingering_close came directly
from SO_LINGER screwing up on some systems which came directly from
someone with a SVR4 system having trouble with sent data being
truncated.  That doesn't mean later things weren't done on the
assumption of it being there.

The most telling thing I could find is from Roy Fielding:

  Yes, please do -- I couldn't see any obvious need for the NEED_LINGER
  once 1.1 is out, and I'd like to have that behavior on all systems
  in order to avoid some problems with persistent connections and
  pipelining.  Perhaps we could set it up as

'that' thing he would like to have appears to be lingering_close.  

Hmm.  Perhaps we could see a similar thing with keepalive persistent
connections... if the server closes the socket after data is sent from
the client but before the client knows it has been closed, the client
will get more of an error than if lingering_close was there to eat up
the information.  However, I'm not sure if in the long run just
silently discarding is a good idea.  

On Tue, 21 Jan 1997, Randy Terbush wrote:

> > Ok, I can replicate the problem now.  Happens if I don't use
> > lingering_close, doesn't if I do.  
> > 
> > Boy is Navigator Gold lame.  This is the first time I have used it and... 
> > well... lame.  It shows my password for an instant in the status line at
> > the bottom when I'm doing a PUT upload.  Sheesh.  Well, I suppose I should
> > be happy that it can't be much worse than FrontPage (server side) for
> > security... 
> > 
> > Now the trick is a fix.  Hopefully not too hard.  Aha.  I think the
> > problem is that as soon as Apache gets an invalid authorization, it sends
> > out a whine message and closes the connection.  However, Netscape is still
> > sending the file at the same time.  As soon as Apache finishes sending it,
> > it closes the connection.  Netscape is still trying to write, so it whines
> > when the connection is closed.
> > 
> > lingering_close() gets around this by slurping up and throwing away the
> > data that Netscape sends.  
> > 
> > I have no clue about PUT and how that stuff is supposed to work, so I will
> > have to check the RFC.  I'm cc:ing this to the list so anyone who has some
> > comments on how the server should handle the above situation can enlighten
> > me.  Should the server just slurp up all input coming from the client if
> > it needs to generate an error?  Could be a Netscape bug. 
> 
> Funny, this is beginning to sound familiar. :)  As I remember,
> Dirk VanGuilik has looked at this some as well. You might grep
> through the archives for PUT. It all comes back to me that this 
> is the reason that RST added lingering_close(). Whether or not
> there is another way is the question.
> 
> I'm out for the night...
> 
> 
> > On Mon, 20 Jan 1997, Randy Terbush wrote:
> > 
> > > 
> > > Did you find that email in the archive where a 1.1.1 user solved
> > > a problem he was having with PUT by including the lingering_close()
> > > code?
> > > 
> > > That triggers another memory for me. It was RST who wrote the
> > > lingering_close() code. It would have probably been included about
> > > the same time he was looking into improving PUT support. Makes sense
> > > that we need to still allow received data to trickle in on a PUT.
> > > 
> > > Something to think about as we test this...
> > > 
> > > 
> > > 
> 
> 
>