Re: Lingering Close

["Roy T. Fielding" <[e-mail]>]

This was addressed in passing for a related issue ...

http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2257

....Roy

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
>