W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2010

Re: 100 Continue and Expects

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
Message-ID: <20100329232022.GB9876@shareable.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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:17 GMT