gambas/rapidsvn/subversion : avoit 413 entity too large, avoit 411 Length required

Subversion 1.8.0 has switched from neon to serf for HTTP access. The Serf-based HTTP access library would use chunked transfer encoding for most requests.

Here we cleared and made recomendations and solution on mixed environments, for those that using not well configured linuxes (such those using rolling releases as alpine, arch etc) and stupid winbuntu based:

BACKGUARDS PROBLEMS: using 1.8 agains 1.7/1.6 servers:

Many issue come with migrations, not all are good: as documented: http://subversion.apache.org/docs/release-notes/1.8.html#411-length-required
When the mod_dav_svn Subversion server is fronted by a proxy or are by passing using reverse proxy web server Subversion would sometimes either treat this as a fatal error, theres the two most comman cases:

CASE 1: 411 Length required:
..such as Nginx prior to 1.3.9 or hiawatta (if are acting as reverse proxy frontend) will responds with a 411 Length Required, Subversion would sometimes either treat this as a fatal error, such as:

% svn commit 
POST of '/svn/project1/!svn/me': 411 Length Required

CASE 2: 413 Request entity too large:
Also if u use mixed environment from venenux and newer stupid debians and alpine linux, could'n chekout newer clients agains well stable 1.5 or 1.6 older servers, so will raise fatal error such as:

% svn cchekout http://domain/svn/project1
svn: E175002: Unable to connect to a repository at URL
svn: E175002: Unexpected HTTP status 413 'Request Entity Too Large'

CLIENT SIDE SOLUTION that must be made:
A http-chunked-requests option has been added to the ~/.subversion/servers per user configuration file. Users who wish to avoid the additional request may set that option to yes or no in order to short-circuit the additional request and avoid making it. We recommend not to set that option (or to set it to its default value, auto) unless you have special circumstances which require it (such as an unusually high latency).

When using clients version 1.8/1.9, agains olders servers 1.7/1.6/1.5 versions, you must set this to "no" in order to avoid the described problems.

SEVER SIDE SOLUTIONS and recomendations:
There options must be set in server, specially if your server subversion software differts from subversion clients, to already go better the compatibility in high latency and high traffic sidtes

config option	apache2	lighttpd	Value must
maximum size of andXML-based request body	LimitXMLRequestBody	server.max_request-size	0
Limit the size of data in body request client	LimitRequestBody	server.max_request-size	2097152
number of requests allowed per connection alive	MaxKeepAliveRequests	server.max-keep-alive-requests	7500

Of course, lasted option its only if u configured a Keep Alive to "on" that increase performace respect each client connection, but of course assumed u have already at least 1G to 2G of RAM memory on server hardware.

RECOMENDATIONS:

For those with multipurposes sites, the most realitable are using two servers, one with main entry point using lighttpd, and other with apache2 and subversion. The server with lighttpd will acts as proxy reverse, let the apache only for subversion or git. Apache could'n rely for high traffic performance, and lighty are made for that work!

The benefits of using KeepAlive, and Subversion newer options is an increase in the speed and reliability of svn while reducing cpu usage since it will not open and close as many connections when checking out code.

Those all are stupids, subversion team do not tell the complete history:

On middle sites with few repositoryes, these are good, but.. the downside is that memory usage will increase due to the fact that svn will be holding many connections at same time and waiting for requests and responses over those connections. So make sure to monitor memory usage and gauge what is right for you.

In conclusion, switch to Git and lighttpd! Default values of lighty are the recomended for git and high traffic sites.