httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@gonzo.ben.algroup.co.uk>
Subject Re: more lingering_close...
Date Sun, 09 Feb 1997 20:10:30 GMT
Jim Jagielski wrote:
> 
> Ben Laurie wrote:
> > 
> > Hang on. I understood up to this point (finally), but surely this is wrong?
> > If the server isn't doing an l_c(), then it won't have half-closed at this
> > point, it will have full-closed, and hence the RST's are exactly what is
> > expected. In this case, we should definitely half-close (which is surely the
> > point of l_c()?), or wait for the client to complete their send (which may be
> > lame - but since the spec doesn't give us a slot at this point in the protocol
> > to say "OK" or "Oops", we shouldn't really be talking or closing connections
> > yet).
> > 
> 
> The problem that I see with waiting until the send is completed is
> that it's either all or nothing... We must continue to wait until
> we rec the AllClear from the client. If we have a timeout then we
> are once again in the position where we close the link before
> the "client is ready"; if we continue to wait, then for slow clients
> or, even worse, clients that just hang there and never finish, we
> tie up a process and never close the link. Even SO_LINGER in the
> socket layer waits a certain amount of time (or, well, it _should_
> wait).

I think we need to be clear here. The scenario described is one where there is
a client with a slow link doing a PUT which fails (because the URL [or some
other bit of header] is bad). The client may, as a result of the slow link,
not get the error message, because, well, I'm not sure why. I thought I
understood, but I'm still digesting Marc's tcpdump and Stevens. I'm beginning
to think that we've made a more fundemental error. An l_c() may fix it, but
I'm not convinced that this isn't just hiding the true error.

A timeout is a different matter. We should not l_c() a timed out connection -
that is silly - we are aborting it, because it isn't behaving, so trying to be
nice to it is self-destructive.

Cheers,

Ben.

-- 
Ben Laurie                Phone: +44 (181) 994 6435  Email: ben@algroup.co.uk
Freelance Consultant and  Fax:   +44 (181) 994 6472
Technical Director        URL: http://www.algroup.co.uk/Apache-SSL
A.L. Digital Ltd,         Apache Group member (http://www.apache.org)
London, England.          Apache-SSL author

Mime
View raw message