W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: Lingering Close

From: Roy T. Fielding <fielding@gbiv.com>
Date: Sun, 19 May 2013 16:38:05 -0700
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <ECED220A-63AA-44B7-BB8C-224A1340FAB2@gbiv.com>
To: Zhong Yu <zhong.j.yu@gmail.com>
This was addressed in passing for a related issue ...



On Nov 28, 2012, at 9:08 AM, Zhong Yu wrote:

> 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 Sunday, 19 May 2013 23:38:18 UTC

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