Re: Lingering Close

On Wed, Nov 28, 2012 at 11:08:42AM -0600, 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)

No, there are several issues with this, among which :
  - bogus clients which still send a late CRLF after a POST will trigger
    an immediate reset from the server's TCP stack before the end of the
    transfer if the connection is closed without lingering. This results
    in the common problem of truncated responses ;

  - "lingering" here clearly means the work performed by the TCP stack
    which is performed by default. If we remove this and talk about
    just a close, some people will believe that they can explicitly
    disable lingering, which is totally wrong as this also kills all
    pending data and truncates the response as well.

The main problem is that HTTP is not well suited for use with TCP (!).
But we have it now and we must do whatever we can to maximize chances of
successful transfers. The two problems of TCP are :
  - application is not aware that the remote end has received everything.
    An application-level ACK from the client would have solved this ;

  - client must never be encouraged to close first otherwise it quickly
    faces the 2 MSL problem with sockets in TIME-WAIT and cannot open new
    ports for several minutes whatever the setsockopt() it did. Still,
    sometimes we don't have much choice.

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

Then these ones most likely perform the half-close transparently for you,
and certainly don't disable lingering!

I think the wording is appropriate here. If it's ambiguous, maybe it could
be improved, but I didn't find anything useless there at least.

Regards,
Willy

Received on Wednesday, 28 November 2012 17:45:17 UTC