Version 3.0 works very well on IIS6 as a Subversion proxy

Jun 10, 2009 at 9:23 PM

I am very pleased to report that the latest version of Url Rewriter 3.0 works without a glitch as a proxy allowing remote access to Subversion via IIS6. I was looking for a solution to the problem of how to host a SVN repository on a Windows virtual server, where direct access to Apache is not allowed and after trying svniis SvnProxy without much success and even attempting to develop our own reverse proxy in C# (easy for straight http, surprisingly complex for the SVN implementation of WebDav with the chunked problems and all the extra verbs) I have stumbled upon the latest release of Managed Fusion Rewriter, and voila! it works without a glitch so far. Here are just a few observations from my tests:

- VisualSVN is very easy to setup under IIS6 (as localhost:81)

- it was necessary to update .NET to 3.5 SP1 (with bare .NET 2.0 some methods releted to the integrated pipes were missing)

- the usual setup for a wildcard filter must be done for a chosen subdomain.

- a single rule is all that is needed in ManagedFusion.Rewriter.txt:

RewriteRule ^/(.*)   http://localhost:81/$1 [P]

Well done Nick and thank you for sharing your great software.

 

Jun 20, 2009 at 9:38 AM
Edited Jun 20, 2009 at 1:06 PM

Just to follow up: there is a problem when the file names or path names contain spaces or characters like #, that should be  url-encoded. Checking out a repository works well, however committing of files fails because the original spaces or special characters are not encoded properly. This seems to be related to the "Location: " header which is returned containing spaces instead of %20. All what is needed to  fix this issue  would be to use

responseLocationUrl.Uri.OriginalString 

instead of

responseLocationUrl.Uri.ToString(). 

I have tried to upload a patch, but it might be easier to simply correct this on line 269 of ProxyHandler.cs.

Coordinator
Jun 28, 2009 at 2:15 PM

Patch uploaded correctly.  I will update this forum post when it is released later today.  Thanks for finding this bug for me.

Nick

Jun 28, 2009 at 7:07 PM

Thank you for acknowledgment, Nick, I have been testing your Rewriter for Subversion access now for several weeks and it works for most of the the simple scenarios. However, there is still some problem with the COPY verb, this is used only rarely when restructuring the repository, I will investigate details of this issue and report a bug later.

Patrik.

 

Coordinator
Jun 28, 2009 at 7:56 PM

If you find something I would like to intigrate it in.  But I have to warn you, the ASP.NET System.Web.HttpRequest doesn't play nicely with WebDAV headers which may be part of the problem with COPY.

Coordinator
Jun 29, 2009 at 2:55 AM

The download has been updated with the latest patch

Jul 24, 2009 at 10:26 AM

Just to follow up on the COPY problem, it only occurs when https is used externally to access IIS and does not occur when htttp is used.  This seems to be a common problem with Subversion and is not specific to Url Rewriter 3.0

see: http://weblogs.asp.net/mnissen/archive/2008/12/28/solution-for-subversion-502-bad-gateway-problem-when-using-forefront-as-reverse-proxy.aspx

So everything works well with http externally, presumably the latest HTTPS Proxy Problem is also related? Would it help to use RewriteCond %{HTTPS} =off ?

Aug 11, 2009 at 1:57 PM

I have just setup a svn proxy my self.

spanel you say:

VisualSVN is very easy to setup under IIS6

It is my understanding that VisualSVN uses apache and that IIS is not supported can you explain how and why you chose to host on IIS.

Can I also ask did you get the VisualSVN 'web view' to work as I just get xml returned.

 

I also noted that the default settings are fine for doing a simple reverse proxy (default rules file is ManagedFusion.Rewriter.txt) I did not have to have anything in the Managed Fusion config section but I did still need the definition or I get a null reference exception.

 

 

<configSections>
	<section name="managedFusion.rewriter" type="ManagedFusion.Rewriter.Configuration.ManagedFusionRewriterSectionGroup"/>
</configSections>

 

It would be nice if this section was omitted the default settings where used.

Aug 11, 2009 at 2:22 PM
Edited Aug 11, 2009 at 2:50 PM
gambrose wrote:

It is my understanding that VisualSVN uses apache and that IIS is not supported can you explain how and why you chose to host on IIS.

The reason was to use already established (contracted and paid for) virtual server hosting solution that runs on IIS and does not allow opening ports for Apache directly. However, using the Rewriter allowed us to install Apache + Subversion on a local port 81 and make it accessible through the virtualised IIS.

Web view works fine, just make sure that /svnindex.xsl is accessible from the root of the web site, that was why I used direct mapping from the root of Apache to the root of a subdomain on IIS rather than a virtual directory.

RewriteRule ^/(.*)   http://localhost:81/$1 [P]

I do not understand the last question about configSections. I just simply used the following without any messing in Web.config:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
	<configSections>
		<section name="managedFusion.rewriter" type="ManagedFusion.Rewriter.Configuration.ManagedFusionRewriterSectionGroup"/>
	</configSections>
	<managedFusion.rewriter xmlns="http://managedfusion.com/xsd/managedFusion/rewriter">
		<rules engine="Apache">
			<apache defaultFileName="ManagedFusion.Rewriter.txt" />
		</rules>
		<rewriter>
			<proxy useAsyncProxy="true" />
		</rewriter>
	</managedFusion.rewriter>
	<system.web>
                <customErrors mode="Off"/>
		<httpModules>
			<add name="RewriterModule" type="ManagedFusion.Rewriter.RewriterModule, ManagedFusion.Rewriter"/>
		</httpModules>
	</system.web>
</configuration>
Aug 11, 2009 at 2:36 PM
Edited Aug 11, 2009 at 2:36 PM

Just for the sake of completeness, here is my ManagedFusion.Rewriter.txt

RewriteEngine On

RewriteRule ^/$   http://www.MAINWEBSITE.com/ [R,L]

RewriteRule ^/svn$   /svn/ [R,L]

RewriteRule ^/(.*)   http://localhost:81/$1 [P]

The first rule is to divert any  (most likely unauthorised) access attempts to the subdomain default page onto the main site (as all the valid requests should have a file or path name given). The second rule is fixing missing trailing slash after /svn when users are initiating the session manually and finally the last rule is doing the regular work.

Aug 13, 2009 at 8:28 AM
Edited Aug 13, 2009 at 8:29 AM
spanel wrote:

Rewriter allowed us to install Apache + Subversion on a local port 81 and make it accessible through the virtualised IIS.

This is my scenario as well. I though you might have found a way not use Apache at all.

 

spanel wrote:

Web view works fine, just make sure that /svnindex.xsl is accessible from the root of the web site, that was why I used direct mapping from the root of Apache to the root of a subdomain on IIS rather than a virtual directory.

Thanks for the explanation I am in a situation where i am using a virtual dir by coping the svnindex.xsl and associated files in to my root IIS dir fixed this problem.

 

The config thing is that I have a personal preference not to put configuration in the web config that is the default anyway.  So I left out the rewriter config section altogether.

But I still needed to add the definition for the section to the web.config even though I am not supplying and config which I see as a bug and so was trying to leave feedback.

 

Thanks for your help with getting this running for me.

May 14, 2010 at 8:02 AM
Edited May 14, 2010 at 8:07 AM
spanel wrote:

Just to follow up on the COPY problem, it only occurs when https is used externally to access IIS and does not occur when http is used.  This seems to be a common problem with Subversion and is not specific to Url Rewriter 3.0

see: http://weblogs.asp.net/mnissen/archive/2008/12/28/solution-for-subversion-502-bad-gateway-problem-when-using-forefront-as-reverse-proxy.aspx

So everything works well with http externally, presumably the latest HTTPS Proxy Problem is also related? Would it help to use RewriteCond %{HTTPS} =off ?

Clearly this is a general problem with trying to proxy a SVN back-end server over https.

See also  http://wiki.uniformserver.com/index.php/Reverse_Proxy_Server_2:_SVN3_over_https

Is there a rule for UrlRewriter equivalent to the suggested solution?

RequestHeader edit Destination ^https://(.*)$ http://$1