On Tuesday, December 17, 2013 10:32:34 AM UTC-5, Branko Čibej wrote: > > On 17.12.2013 16:19, Stuart MacDonald wrote: > > The Wireshark trace shows clearly and conclusively this is a bug in > > the client. The client drops the connection by sending a FIN packet > > unexpectedly. > > It could be waiting for a response from the proxy that never reaches the > client, and dropping the connection after a timeout. > > Regardless, you should still try to reproduce this with the latest > client (ideally, both latest 1.7 and 1.8) to determine if the problem > has been fixed. Especially in 1.8, there have been a lot of improvements > in the HTTP protocol driver. >
I'm using WANdisco's packages to test with, as it turned out to be easier to get those set up than to compile from source with all the optional bits I need. I have seen the exact same issue on 1.7.14: svn: E175002: REPORT of '/svn/repos/<name>/!svn/me': Could not read response body: connection was closed by server (http://<server>) and the Wireshark capture shows the client sending a [FIN, ACK] to close the connection, despite it only being a fraction of a second since the last server traffic. This always occurs just after the TCP window opening up again, not sure if that's significant. This *also* occurs on 1.8.5, although the error message is more informative: svn: E120106: ra_serf: The server sent a truncated HTTP response body. The Wireshark capture is *exactly* *identical*; after some server traffic, the TCP window opens up and the client sends a [FIN, ACK] to close the connection. Having taken a closer look at the network captures; the failure pattern is always: - 1380 byte packets from the server - an ACK from the client - a TCP window update from the client (the window hadn't gone to 0 in any cases, this is just a regular update) - in one case there's another window update from the client - a delay of 0 - 4 seconds where there is no traffic in either direction - the client sends the [FIN, ACK] Now, I'm not sure what constitutes a truncated HTTP response body, as the traffic looks the same in both cases, large blocks of encoded data. So I think the 1.8.x error message is also incorrect, but possibly less incorrect than the 1.7.x error message. What's the next step? ...Stu
