Re: IRIX and FIN_WAIT_2 timeouts

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

On Fri, 31 Jan 1997, Ben Laurie wrote:

> Jim Jagielski wrote:
> > 
> > If OS vendors keep on hacking their stacks we'll never know...
> > 
> > Note that this never came up before 1.2 and lingering_close... Coincidence??
> 
> Yeah, but I thought we'd fixed it all in the last beta? Am I wrong?

It has been cleaned up and fixed several possible problems as well as
we could do, but I don't think it is fully fixed.

I'm tempted to post lingering_close() to c.p.tcp-ip and see what comments
Gurus have.  A Sun TCP/IP guy didn't see anything wrong with the
implementation; I am sending it to the SGI guy for comments when I clear
my head.

On Fri, 31 Jan 1997, Jim Jagielski wrote:

> Note that this never came up before 1.2 and lingering_close... Coincidence??

No.  lingering_close() is causing 95% or more of the problems, out of 
a dozen or so people I have checked with.

On Fri, 31 Jan 1997, Jim Jagielski wrote:

> Andrew Wilson wrote:
> > 
> > Jim Jagielski:
> > > 
> > 
> > [ irix tcp/ip upgrade... ]
> > 
> > > Boy this doesn't feel right.... Something in Apache causing people
> > > to add patches to their TCP/IP implementations which can arguably
> > > be said to violate the RFC.

However, more people would argue that _not_ having the timeout is a bug
and a problem with the standard.  In fact, the Sun guy I talked to
refused to call the fact that SunOS 4.x didn't have a timeout anything
other than a bug.

> > > Something tells me if we weren't #1 and had the muscle, and we had
> > > this problem, that we'd find some other way to fix it...
> > 
> > Mmm, is Apache in the wrong in this case?
> > 
> 
> 
> Well, I think that there is something very wrong with the way
> we are doing lingering_close... something that triggers the
> FIN_WAIT_2 problem. It looks like so many people are complaining
> that OS vendors are patching their tcp/ip stacks to include
> a timer on the FIN_WAIT_2 state, soemthing which make me
> uneasy as far as it even being allowed.

Don't be uneasy about having a timer on FIN_WAIT_2.  It is a good thing,
and not just for Apache.  Some of them aren't implemented very well,
but that's life.

I don't think there is anything very wrong with lingering_close.
However, there may well be something a bit wrong which is causing
a major problem in some cases.

> 
> In any case, Apache's lingering_close is causing problems... we don't
> know why, but we are so popular that instead of the pressure being
> on us to fix it, OS vendors are hacking their stacks.

^hacking^fixing

Apache may be the direct cause for some of them, but this problem isn't
really new it just hadn't been that important until now.  

You ask why other servers don't have the problem?  How many other servers
implement HTTP/1.1?  I am not aware of many, and there are even fewer 
in widespread use.  

How many even implement the HTTP/1.0 keepalive hacks?  None of the
Netscape servers I checked did.  IIS 3.0 does, but NT is different.

Note that it is entirely possible to work around the PUT problem
without lingering_close by simply not sending a response, even if
it is an error, until the entire document is received by the server
(newer Netscape servers do this) but I think that's lame.  Regardless,
that doesn't solve the persistent connection problem.

If we did not support HTTP/1.1 or the keepalive hack on top of 1.0,
we could get rid of lingering_close(); the problems with error
conditions can be handled as mentioned above.