TortoiseSVN checkout failed error svn: E120106: ra_serf: The server sent a truncated HTTP response body

Question

TortoiseSVN shows the error svn: E120106: ra_serf: The server sent a truncated HTTP response body during checkout operation. How to solve the problem?

Answer 1

Incorrect Proxy Settings can cause the same error message.

I have encountered the exact same error at different moments during the checkout. The first few files always succeeded, but after 5-10 files the ra_serf error appeared. Same happened with large and small files.

After some trial and error (other hardware, wired connection) I was not closer to a solution. I decided to check all Tortoise SVN settings and found the simple answer: my proxy settings were not correct!

Answer 2

I experienced the same issue, but in the context of our CI system teamcity. rather than using teamcity itself to checkout, some scripts do perform manual svn checkout and caused this error.

Internal SVN clean checkout canceled on large repositories for working copy format 1.7 using the svn.exe via script instead of build-in teamcity SVN with the message: "svn: E120106: ra_serf: The server sent a truncated HTTP response body."

• clean checkout of small repository works regardless of working copy format
• clean checkout of large repository works using working copy format 1.5
• using export instead of checkout works
• using teamcity 8.1.5 internal svn client works (no idea why)
• using svn client 1.7 instead of 1.8 results in a similar timeout related error: "svn: E175002: REPORT of '/!svn/me': Could not read response body: Secure connection truncated"

Increasing the SVN timeout value on the server did indeed fix the problem and neither the "ra_serf" nor the "secure connection truncated error" occurred since.

Aniket Thakur suggestion of reverting the svn client version did have effect on this issue, yet I was unable to find the right version. (if there is one)

Sanmat Jhanjhari suggestion of decreasing the compression level is not only part of the accepted solution but the reason this might work is that it keeps the response time between SVN server and client steady and compressing large files no longer cause timeouts.

changing the working copy to 1.5 is a client side only alternative one could take to resolve this issue. the reason this works is most likely related to the way the data is compressed, but I couldn't figure out the exact reasons.

using export is a dire client side alternative one could take in case you are only interested in the data itself and do not need it to be a repository. export behavior is slightly different though. for example it does not overwrite existing files. I also couldn't figure out why this works compared to normal checkout.

Answer 3

Set following key-value in the SVN configuration file. That's it.

DeflateCompressionLevel 5

1 is the lowest value. 9 is the maximum value.

Answer 4

Some ideas from TortoiseSVN developer:

The data sent is too big and the server closes the connection due to reaching a limit.

Possible steps which can help fix this issue:

• Increase the timeout value on the server
• set compression level to zero on the server (will make everything slower but helps with this issue)
• make sure all proxies that are in between you and the svn server also have the timeout values increased

Answer 5

Make sure to use the latest and most up to date Subversion client version available. If the problem still occurs, you should

• contact your system administrator to check the network for connection problems,
• ensure that a proxy you may have between the client machine and Subversion server is working properly and is not killing the connection prematurely,
• ensure that an antivirus you may have installed on the client or server computer is not interfering with the Subversion HTTP(S) traffic. You must add exception / exclusion rule that will disable on-access or traffic scan to and from your Subversion server.

NOTE: Downgrading Subversion client is a wrong and ugly workaround. The problem has to be solved on the network.

Answer 6

Then take update instead of again checking out ... Don't delete the Checked out copy, just update it again.