httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: lingering_close
Date Wed, 22 Jan 1997 04:25:00 GMT
I would suggest that after we agree on some minor unlikely-to-fix-things
(IMHO) lingering_close() patches (covering things already discussed
somewhat) we should look at getting the next beta out?  I would like to
see the FIN_WAIT_2 thing solved completely first, but since there doesn't
look to be an easy answer...

On Tue, 21 Jan 1997, Jim Jagielski wrote:

> Marc Slemko wrote:
> > 
> > If it takes more than keep_alive_timeout seconds for the server to finish
> > sending the data to the client, doesn't the current lingering_close still
> > offer the possibility of truncating data on the broken SVR4 systems,
> > especially if keep_alive_timeout is really low?
> > 
> > Perhaps we need to set the select timeout to something like
> > max(keep_alive_timeout, 10), where 10 is some number that probably isn't
> > 10? 
> > 
> > I should have a lingering_close cleanup patch (mostly stuff discussed
> > already) available for comments later tonight...
> > 
> Does it make sense to continue slurping data even if we know
> it's just gonna be thrown away. This seems like a real easy
> way to overload servers... PUT some large data, making sure authent
> fails - rinse - repeat

I don't think that is an interesting attack because it wastes the
attacker's bandwidth.  You can tie up a server far more easily if you
really want to...

The whole point of needing lingering_close() is that we have to keep
taking data until the client acknowledges that it has gotten all the data
we sent it.

> I'm not sure what the answer is, but this seems nasty.
> Also, the FIN_WAIT_2 stuff seems to me looking less like an
> artifact of lingering_close, what with the 1.1.3 reports....
> Are we possibly setting some sock-opts we shouldn't? Maybe
> keepalive or nodelay.... I know, I'm reaching here :)

Don't get confused by what Roy reported.  He is quite correct in what he
reported and it is something of importance and needs to be considered.
However, at least half a dozen people who had servers crashing due to
connections in FIN_WAIT_2 did NOT have the problem using NO_LINGCLOSE; 
ie. NO_LINGCLOSE solved that problem entirely. I only have one I'm still
tracking down that NO_LINGCLOSE did not help, but I suspect NO_LINGCLOSE
may be the solution there too but he just doesn't realize it.  There is
something more at work.

View raw message