In the tcpdump listed below, isn't the next-to-the-last RST also include an ACK of the data previously sent? If that is the case, then the client has received all of the data and ACK'd it but then rudely closed the TCP connection without the normal FIN exchange. Is my reading correct?
19:03:33.106842 IP 10.79.25.20.4266 > 10.79.6.10.80: S 2041799057:2041799057(0) win 65535 <mss 1460,nop,nop,sackOK> 19:03:33.106862 IP 10.79.6.10.80 > 10.79.25.20.4266: S 266508528:266508528(0) ack 2041799058 win 5840 <mss 1460,nop,nop,sackOK> 19:03:33.106945 IP 10.79.25.20.4266 > 10.79.6.10.80: . ack 1 win 65535 19:03:33.107045 IP 10.79.25.20.4266 > 10.79.6.10.80: P 1:269(268) ack 1 win 65535 19:03:33.107060 IP 10.79.6.10.80 > 10.79.25.20.4266: . ack 269 win 6432 19:03:33.134401 IP 10.79.6.10.80 > 10.79.25.20.4266: P 1:270(269) ack 269 win 6432 19:03:33.134442 IP 10.79.6.10.80 > 10.79.25.20.4266: F 270:270(0) ack 269 win 6432 19:03:33.134548 IP 10.79.25.20.4266 > 10.79.6.10.80: R 269:269(0) ack 270 win 0 19:03:33.134562 IP 10.79.25.20.4266 > 10.79.6.10.80: R 2041799326:2041799326(0) win 0 -Bryan On Mon, Aug 2, 2010 at 10:45 PM, Willy Tarreau <[email protected]> wrote: > On Wed, Jul 28, 2010 at 05:51:18PM -0700, Bryan Talbot wrote: > > I'm trying to figure out what _exactly_ the CD termination code means. > The > > docs says: > > > > CD The client unexpectedly aborted during data transfer. This can > be > > caused by a browser crash, by an intermediate equipment between > the > > client and haproxy which decided to actively break the > connection, > > by network routing issues between the client and haproxy, or by > a > > keep-alive session between the server and the client terminated > first > > by the client. > > > > > > Does this mean that clients MUST have not received some of the data or > > could a client have received all of the data from the response? > > it means that the client closed the response socket before all data was > consumed. > > > What's an unexpected abortion vs a normal termination? > > An unexpected abortion is when the system reports a socket error while > there were still some data to send in the buffer. A normal termination > is when there is no error and that all pending data were sent before > the client closed. > > > I have a client (windows using a MS xml library to make http requests) > > which always ends up with CD-- terminations, but the software seems to > > work properly otherwise. > > It is possible that this client only needs something at the very > beginning of the response and that it aborts connections once it > gets what it needs. This is what happens with health checks too > if too large objects are sent in response. From a protocol point > of view this can be seen as dirty, but if the client does not need > anything else, it results in cheaper network use because less data > get transferred. > > If you're sure to see this for every request, it would be nice to > get a capture of a full request/response from both sides to see > what it looks like (use tcpdump -s0 to get full packets). I suspect > that you'll see an RST packet coming from the client to haproxy > while haproxy is sending data. > > Regards, > Willy > >
