svn file rename fails, but recreating a new file and copying the previous contents works

[William Muriithi]

Hello,

I have this setup:
- httpd-2.4.37-43
- subversion-1.14.1-1
- mod_dav_svn-1.14.1-1
- openssl-1.1.1k-5

The svn on Rocky Linux that is accessible only over https (Apache) and
everything works fine with exemption of "svn mv" command. Below is a
series of commands on how to trigger the error.

svn mv xyz.txt abc.txt
svn ci -m 'Renaming a dummy file for changes"
Adding abc.txt
svn: E175002: Commit failed (details follow):
svn: E175002: Unexpected HTTP status 502 'Bad Gateway' on
'/svn/pro/!svn/rvr/4748/abc.txt'

However, a new file abc.txt will get committed without any problem.

The problem seems to match a problem reported here.
https://community.opalstack.com/d/608-svn-unexpected-http-status-502-bad-gateway/3

This is dated and I am not sure it's still valid. Has anyone seen
this problem on a fairly recent svn server? Is there any way of
resolving it if its still a problem with current svn?

Regards,
William

[Mark Phippard]

On Fri, Feb 18, 2022 at 5:52 PM William Muriithi
<william....@gmail.com> wrote:
>
> Hello,
>
> I have this setup:
> - httpd-2.4.37-43
> - subversion-1.14.1-1
> - mod_dav_svn-1.14.1-1
> - openssl-1.1.1k-5
>
> The svn on Rocky Linux that is accessible only over https (Apache) and
> everything works fine with exemption of "svn mv" command. Below is a
> series of commands on how to trigger the error.
>
> svn mv xyz.txt abc.txt
> svn ci -m 'Renaming a dummy file for changes"
> Adding abc.txt
> svn: E175002: Commit failed (details follow):
> svn: E175002: Unexpected HTTP status 502 'Bad Gateway' on
> '/svn/pro/!svn/rvr/4748/abc.txt'
>
> However, a new file abc.txt will get committed without any problem.
>
> The problem seems to match a problem reported here.
> https://community.opalstack.com/d/608-svn-unexpected-http-status-502-bad-gateway/3

That is a very common problem. It happens when the server is sitting
behind some kind of load balancer or proxy that is terminating the SSL
connection. The issue is that the svn copy and move commands use
WebDAV HTTP methods. These include the HTTP "Destination" header and
it needs to be rewritten by the proxy to change the https to http.

Here is one example:
https://stackoverflow.com/questions/2479346/502-bad-gateway-with-nginx-apache-subversion-ssl-svn-copy

The answer will depend on the Proxy being used.

Mark

[William Muriithi]

Morning Mark

Thanks a lot for the quick suggestion. I don't have a proxy in front
of the SVN though. The svn client (Which is also subversion 1.14)
connects to apache server that is running mod_dav_svn to serve a svn
repo. I am not sure if this apache server can then be called a proxy,
as all http based svn would then have a proxy. The same apache is the
one that handles ssl termination.

I do have two DNS A records. Not sure if this can cause this
breakage. The hostname is called repo.example.com. So there is a
DNS A record of repo.example.com pointing to 192.168.20.6. However to
allow easy server migration, the svn clients use another A record
that points carbon.example.com to the current SVN server, in this case
carbon.example.com point to 192.168.20.6. I can't honestly see this
being a problem but sharing in case it's a problem and I am in the
dark.

I just thought sharing my actual configurations could also help.
Below is how apache config looks like:


<VirtualHost *:443>
ServerName carbon.example.com
Header always set Strict-Transport-Security "max-age=31536000;
includeSubDomains"
<FilesMatch "\.pdf$">
Header set Content-Disposition inline
</FilesMatch>

MaxKeepAliveRequests 1000

<IfModule dav_svn_module>
SVNCacheRevProps on
SVNInMemoryCacheSize 3145728
SVNCacheTextDeltas On
SVNAllowBulkUpdates Prefer
SVNCacheFullTexts On
SVNUseUTF8 On
</IfModule>

<Location /svn>
DAV svn
SVNParentPath /var/repos/svn
SVNListParentPath On
SVNReposName "SVN Repositories"
LimitXMLRequestBody 0
LimitRequestBody 0
AuthType GSSAPI
AuthName "SVN Account"
GssapiConnectionBound On
GssapiBasicAuth On
GssapiNegotiateOnce On
GssapiLocalName on
BrowserMatch Windows gssapi-no-negotiate
AuthzSendForbiddenOnFailure On
GssapiCredStore keytab:/etc/httpd/conf.d/httpd.keytab
GssapiSignalPersistentAuth On
GssapiSSLonly On
AuthzSVNReposRelativeAccessFile authz
AuthzSVNGroupsFile /var/repos/svn/glacier/conf/groups
Require expr %{REMOTE_USER} =~ /@example.com$/
</Location>
<Location /svn/svn-status>
SetHandler svn-status
</Location>


RewriteEngine on
RewriteCond %{HTTP_HOST} !^carbon\.example\.com [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/?(.*) https://carbon.example.com/$1 [L,R,NE]

RewriteCond "%{QUERY_STRING}" "^$"
RewriteRule "^/$"
https://example.sharepoint.com/IT/SitePages/Repositories.aspx
[L,R=301]

</VirtualHost>


Regards,
William

[Mark Phippard]

Without understanding all of the details of what you are doing with
VirtualHost I would say the solution lies in that final section where
you are doing Rewrites. You need to add a rule to rewrite the
Destination header. It will come in populated with the URL the end
user is using so you need to rewrite it to the internal value.

I know when we are just rewriting the protocol the Directive looks like this:

RequestHeader edit Destination ^https http early

You will need to do a bit more since you are rewriting the full host
section. I am guessing you can figure it out from here though.

Mark

[Mark Phippard]

The documentation for the HTTP COPY method will give you an idea what
is going on:

https://datatracker.ietf.org/doc/html/rfc4918#section-9.8.6

SVN sends this method to the server, the Destination header contains
the URI where the source item is being copied/moved to. Since you
rewrite the server name before forwarding a request to the SVN server
you also need to rewrite the value in this header.

Mark