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

On Fri, 18 Feb 2022 at 18:11, Mark Phippard <markp...@gmail.com> wrote:
>
> On Fri, Feb 18, 2022 at 5:52 PM William Muriithi
> <william.murii...@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

Reply via email to