- From: Jamie Lokier <jamie@shareable.org>
- Date: Tue, 30 Mar 2010 00:20:22 +0100
- To: Henrik Nordström <henrik@henriknordstrom.net>
- Cc: Greg Wilkins <gregw@webtide.com>, ietf-http-wg@w3.org
Henrik Nordström wrote:
> But in real-life and experience servers need to be careful as well, and
> is reflected in some other sections of the specifications requiring
> servers to perform a graceful close and/or wait for TCP ACK of the
> response data.
I think it's a good idea to combine graceful close with TCP ACK when
possible, and otherwise to do graceful close. But not TCP ACK alone,
as suggested by your "and/or".
I would caution against depending on TCP ACK *alone*, because it fails
in three scenarios:
1. Sometimes it's HTTPS relayed over a proxy using CONNECT.
Then TCP ACK does not indicate the client TCP has received the data.
2. Many client TCPs will discard received data on reception of the
TCP RST from the closed server TCP, before the client application
receives the data from its TCP.
3. Sometimes data is relayed over a TCP retransmitter.
Then TCP ACK does not indicate the client TCP has received the data.
I've read that some networks do this for all connections, to
compensate for channel characteristics (radio). But I've only
seen it used for certain kinds of tunnelling, and to bypass firewalls.
-- Jamie
Received on Monday, 29 March 2010 23:20:52 UTC