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

Re: Lingering Close

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Wed, 28 Nov 2012 13:24:15 -0600
Message-ID: <CACuKZqEDnuWsMTrBtEFi9es76hNa=SAaD+5nUQxRnO_jVM8EUw@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Thanks Willy, I think I get what you mean by now. FIN should be
initiated by server to avoid the TIME_WAIT problem. Therefore the
half-close step is important.

The current text makes perfect sense to me now.

Unfortunately, this lingering close process cannot be implemented on
top of some APIs; these APIs don't do transparent lingering close upon
close() either. But it is their fault, not the spec's.

Zhong Yu

On Wed, Nov 28, 2012 at 1:08 PM, Willy Tarreau <w@1wt.eu> wrote:
> On Wed, Nov 28, 2012 at 12:20:06PM -0600, Zhong Yu wrote:
>> 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.
>
> OK.
>
>> 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.
>
> No, you're right.
>
>> 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.
>
> I disagree, precisely because if you only close, you risk facing
> the RST.
>
>> > 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
>
> No, because if you don't send the half-close, you can't expect the client
> to close first as it might very well be only relying on the close to get
> the end of the message (old client). Also, even if it's a new client, you
> absolutely don't want it to close first as you might cause it to run out
> of source ports very quickly (think about a proxy).
>
>> >   - "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.
>
> OK.
>
>> > 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.
>
> But I do think that if you simply close, the underlying layers will do
> the lingering for you. However this still means that these APIs are not
> compatible with HTTP/1.0 clients, which is somewhat problematic :-/
>
> Willy
>
Received on Wednesday, 28 November 2012 19:24:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 28 November 2012 19:24:45 GMT