When I try to check in changes using Fedora 22 client svn, version 1.8.13 (r1667537) GNU/Linux 4.1.3-200.fc22.x86_64 and CentOS 7 server subversion-1.7.14-7.el7_1.1.x86_64. I get the error svn: E175002: POST of '/svn/CppAD/!svn/me': 411 Length Required https://projects.coin-or.org) When I follow the suggestions at http://stackoverflow.com/questions/23383676/svn-dav-request-failed-411-content-length-required-http-chunked-requests and add the following to ~/.subversion/server [global] http-chunked-requests = no the error message changes to svn: E160013: POST of '/svn/CppAD/!svn/me': 404 Not Found (https://projects.coin-or.org) which is not much help since I can checkout from that address. It seems that many other people have run into the need to downgrade to subversion 1.8 http://askubuntu.com/questions/453717/i-need-downgrade-from-subversion-1-8-to-subversion-1-7
The 411 suggests there is a proxy between you and the origin server, possibly intercepting the requests, though this is SSL so it's a bit odd. Did you get SSL certificate warnings? The 404 looks like you got the URL wrong, though it could be a proxy too. I can check out https://projects.coin-or.org/svn/CppAD/trunk with F22 svn without any problems. Please try the SVN users list, this almost certainly isn't an SVN bug. http://subversion.apache.org/mailing-lists.html
I run the server the OP is connecting to. The workaround for this issue on the server side is to disable http version 2 protocol for mod_dav_svn with SVNAdvertiseV2Protocol Off It seems that there are issues with Subversion's handling of V2 since its introduction. Older servers (1.6) and/or older clients that don't support it don't have the problem. Disabling chunking on the client side apparently doesn't work either.
I'm really surprised you see any such issues over SSL, since they are typically caused by an intercepting proxy screwing things up at HTTP level. Matthew, do you have problems with other F22 clients committing? Do you have any proxy server between where SSL is terminated and the httpd running mod_dav_svn?
(In reply to Joe Orton from comment #3) > I'm really surprised you see any such issues over SSL, since they are > typically caused by an intercepting proxy screwing things up at HTTP level. > > Matthew, do you have problems with other F22 clients committing? Yes, this has been a general issue since upgrading to CentOS 7. One interesting anomaly: I have two vhosts that provide access to our Subversion repos. One, which also serves Trac, has consistently exhibited this problem. The other, which only serves Subversion access, works for most (but not all) F22 clients. > Do you > have any proxy server between where SSL is terminated and the httpd running > mod_dav_svn? Not that I know of. I am behind a corporate firewall, but AFAIK, access to my server is wide open. Is there a way for me to determine the answer to that?
(In reply to Matthew Saltzman from comment #4) > Yes, this has been a general issue since upgrading to CentOS 7. One > interesting anomaly: I have two vhosts that provide access to our Subversion > repos. One, which also serves Trac, has consistently exhibited this problem. > The other, which only serves Subversion access, works for most (but not all) > F22 clients. Can you find the 411 errors in the access_log generated by the POST requests, and see if those errors correlate with anything in the corresponding error_log for the same vhost? Does trac handle /svn/ or is that mod_dav_svn configured for that location? It really sounds like something is intercepting those requests; if not a proxy then something in the server config itself. If mod_wsgi is handling /svn/ that would explain the 411 as well, since mod_wsgi (in RHEL7) can't handle chunked request bodies either. > > Do you > > have any proxy server between where SSL is terminated and the httpd running > > mod_dav_svn? > > Not that I know of. I am behind a corporate firewall, but AFAIK, access to > my server is wide open. Is there a way for me to determine the answer to > that? If you have mod_ssl configured on that server directly and expect clients to talk SSL directly to the SSL vhost on which mod_dav_svn is accessible, it's unlikely there is a proxy. I note you have mod_nss and mod_ssl installed on that server from the response headers, though I'm not aware it can make a difference. < Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips mod_fcgid/2.3.9 mod_nss/2.4.6 NSS/3.16.2.3 Basic ECC PHP/5.4.16 SVN/1.7.14 mod_wsgi/3.4 Python/2.7.5 mod_perl/2.0.9dev Perl/v5.16.3
https://bz.apache.org/bugzilla/show_bug.cgi?id=54794 This is similar. Having WSGIScriptAlias set too something too broad (e.g. /) would be consistent with the symptoms described.
(In reply to Joe Orton from comment #6) > https://bz.apache.org/bugzilla/show_bug.cgi?id=54794 > > This is similar. Having WSGIScriptAlias set too something too broad (e.g. > /) would be consistent with the symptoms described. Ah, that might explain why trying to get to Subversion via my Trac vhost is exhibiting that behavior, but doing it via a separate vhost works sometimes. The Trac vhost has WSGIScriptAlias set to / because we've always had the URLs https://projects.example.com/ProjectName directed to the Trac page for ProjectName. The separate subversion vhost doesn't use WSGIScriptAlias, but it still seems to fail for some users. Is there an easy way to set WSGIScriptAlias to, say, /trac without also having to change the project URL to https://proejects.example.com/trac/ProjectName? If so, I can try that.
Sure, a RewriteRule can be used to redirect from /FOO to /trac/FOO where /FOO does not match /trac or /svn/.