On Sat, Feb 19, 2022 at 11:07 AM Mark Phippard <markp...@gmail.com> wrote:
>
> On Sat, Feb 19, 2022 at 9:48 AM William Muriithi
> <william.murii...@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
