You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by William Muriithi <wi...@gmail.com> on 2022/02/18 22:52:12 UTC
svn file rename fails, but recreating a new file and copying the previous contents works
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
Re: svn file rename fails, but recreating a new file and copying the previous contents works
Posted by Mark Phippard <ma...@gmail.com>.
On Sat, Feb 19, 2022 at 11:07 AM Mark Phippard <ma...@gmail.com> wrote:
>
> On Sat, Feb 19, 2022 at 9:48 AM William Muriithi
> <wi...@gmail.com> wrote:
> >
> > 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>
>
> 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.
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
Re: svn file rename fails, but recreating a new file and copying the previous contents works
Posted by Mark Phippard <ma...@gmail.com>.
On Sat, Feb 19, 2022 at 9:48 AM William Muriithi
<wi...@gmail.com> wrote:
>
> 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>
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
Re: svn file rename fails, but recreating a new file and copying the previous contents works
Posted by William Muriithi <wi...@gmail.com>.
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 <ma...@gmail.com> wrote:
>
> On Fri, Feb 18, 2022 at 5:52 PM William Muriithi
> <wi...@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
Re: svn file rename fails, but recreating a new file and copying the previous contents works
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Feb 18, 2022 at 5:52 PM William Muriithi
<wi...@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