W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

Re: Lingering Close

From: Jamie Lokier <jamie@shareable.org>
Date: Wed, 28 Nov 2012 19:39:47 +0000
To: Willy Tarreau <w@1wt.eu>
Cc: Roberto Peon <grmocg@gmail.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Zhong Yu <zhong.j.yu@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20121128193947.GC17008@jl-vm1.vm.bytemark.co.uk>
Willy Tarreau wrote:
> On Wed, Nov 28, 2012 at 10:14:16AM -0800, Roberto Peon wrote:
> > I understand the specification of lingering close, however, specifying that
> > the HTTP implementation should make an effort to ensure that the data is
> > received before closing (and that lingering close is one such mechanism) is
> > potentially better.
> I agree but there is no portable way of doing so at the moment unfortunately,
> so basically what the spec requires implies suboptimal processing on all
> standard-compliant HTTP stacks (which basically means draining data from the
> client until it closes).
> > Lingering close is nasty for a number of reasons.The best option here (at
> > least for servers) would be to have some knowledge about when the last ack
> > is ack'd so that it can close the connection from userspace, safe in the
> > knowledge that everything has arrived at the client safely. That is
> > obviously not an issue for this WG< however.
> Exactly, I would love to have this ! We could even imagine an option so
> that the FIN could be sent by the stack while the app layer is notified.

I'm not sure it would work.  When the last ACK is sent from client to
server, the client kernel has the data but the client application
generally doesn't.  If there's post-request data still in flight from
the client, or the client app will send a few bytes more, RST can
still happen, and the client kernel may abort the socket before the
client application has read from its kernel.

-- Jamie
Received on Wednesday, 28 November 2012 19:40:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:07 UTC