Re: Lingering Close

Willy, I thought the term "lingering closed" in the section is self-defined

    a server can perform a lingering close on a connection by [steps...]

the word linger here has nothing to do with its usage elsewhere, like
SO_LINGER option.

I might be wrong if the word "linger" carries a meaning not defined
here but well known to the readers. Please clarify. At least the word
is not in the TCP spec.

Regardless, I certainly do not suggest to abortively close a
connection without seeing outbound data ACK-ed. My point is, the
half-close step is not necessary.

More inline comments below...

On Wed, Nov 28, 2012 at 11:44 AM, Willy Tarreau <w@1wt.eu> wrote:
> 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 ;

It's solved by the draining step, not by half-close

>   - "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.

I do not suggest to disable "lingering" in that sense.

> 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!

It's impossible in these APIs to half-close first, then read;
therefore the current description of "lingering close" cannot be
implemented in these APIs.

>
> 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 18:20:40 UTC