Bug 1264625 - Need to downgrade subversion to 1.7 because 1.8 client not compatible with 1.7 server
Need to downgrade subversion to 1.7 because 1.8 client not compatible with 1....
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: subversion (Show other bugs)
22
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Joe Orton
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-19 09:04 EDT by Brad Bell
Modified: 2015-10-02 07:07 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-21 04:14:15 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brad Bell 2015-09-19 09:04:12 EDT
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
Comment 1 Joe Orton 2015-09-21 04:14:15 EDT
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
Comment 2 Matthew Saltzman 2015-09-21 17:36:42 EDT
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.
Comment 3 Joe Orton 2015-09-22 04:44:32 EDT
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?
Comment 4 Matthew Saltzman 2015-09-22 05:49:26 EDT
(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?
Comment 5 Joe Orton 2015-09-22 07:19:18 EDT
(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
Comment 6 Joe Orton 2015-09-22 07:27:01 EDT
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.
Comment 7 Matthew Saltzman 2015-10-01 22:57:34 EDT
(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.
Comment 8 Joe Orton 2015-10-02 07:07:49 EDT
Sure, a RewriteRule can be used to redirect from /FOO to /trac/FOO where /FOO does not match /trac or /svn/.

Note You need to log in before you can comment on or make changes to this bug.