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
Received on 2013-12-23 18:12:29 CET