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

Re: Lingering Close

From: Willy Tarreau <w@1wt.eu>
Date: Wed, 28 Nov 2012 21:24:30 +0100
To: Jamie Lokier <jamie@shareable.org>
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: <20121128202430.GI7227@1wt.eu>
On Wed, Nov 28, 2012 at 07:39:47PM +0000, Jamie Lokier wrote:
> 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.

Indeed, that's why I proposed a linux patch years ago to avoid sending
this RST until client data were acked, but it was rejected, not being
standards compliant. Anyway, I do think that we'll need to update some
TCP stacks to use HTTP better in the future.

Received on Wednesday, 28 November 2012 20:24:59 UTC

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