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

Lingering Close

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Wed, 28 Nov 2012 11:08:42 -0600
Message-ID: <CACuKZqGcDvFu_r=DWKPv2AkhcbDgoB6jOam3GMLJoz9HFEFSEg@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-21#section-6.2.5
6.2.5. Tear-down

   A server that receives a close connection option *MUST initiate a
   lingering close* of the connection after it sends the final response
   to the request that contained close.

   A server that sends a close connection option *MUST initiate a
   lingering close* of the connection after it sends the response
   containing close.

The 2 MUSTs (of lingering close) are too strong here; a server may
reason that a simple close is enough since there shouldn't be any more
data from client, due to
  1. the request is HTTP/1.0 without "Connection:keep-alive".
  2. the request contains "Connection:close"
We can weaken the texts to "MUST close the connection", and discuss
later when a "lingering close" is needed.

The description of "lingering close" also seems a little off. We
shouldn't ask servers to "half-close" first, because

  1. Half-close is useless since an HTTP/1.1 client usually won't
detect it. The client reads to the end of the response and stops, it
won't read again to find out the EOF. (For HTTP/1.0, EOF is required,
but it's not part of the discussion of lingering close)

  2. Some APIs do not support half-close. Examples in Java: SSL
socket, Netty channel.

So we can remove the "half-close" step from "lingering close" process;
the process is simply: drain inbound data, then close the connection.

This "lingering close" process should work for abstract transport
protocols, as long as the server, while reading from client, can
detect that the client has closed the connection.

Zhong Yu
Received on Wednesday, 28 November 2012 17:09:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 28 November 2012 17:09:22 GMT