subversion commits over http

[Jeanne Boyarsky]

Does anyone know if it is possible to commit SVN via HTTP? I'm thinking some sort of proxy that issues the SVN commands on your behalf. I am aware that you can view the repository via a browser and the hosting company has this set up.

The goal is to be able to commit from an environment that blocks assorted ports including 3690, the port used by SVN. We don't control the hosting company, so changing the SVN port isn't an option.

I'm thinking such a redirect doesn't exist, but no harm in asking.

[David Newton]

I guess you could, maybe check around to see if there's an SVN proxy you could run somewhere?

If the project is checked out via http:// protocol it should be using port 80 anyway, though.

http://www.svnforum.org/2017/viewtopic.php?t=2944

[Ernest Friedman-Hill]

You can do it, easily. HTTPS is preferred, of course, if you can swing it, but I would say the most common SVN setup, in fact, is sitting behind Apache with mod_webdav. It's entirely up to the Apache configuration whether that's served via an HTTP or HTTPS URL. If you can view the repository via HTTP/S, and it's just those very plain-looking pages with no styles, then that is, in fact, the very URL you could use with the SVN client.

[Jeanne Boyarsky]

Dave: I did search for a proxy and didn't find anything.

Ernest: Webdav is definitely set up and I can view the plain white page. That's a good point that we should be able to commit over that instead of 3690. Will try it next week.

[Marco Ehrentreich]

Hi Jeanne,

it simply works like Ernest said. If you use Apache 2 there's a module called mod_dav_svn which does exactly what you want and allows you full read-write access to SVN over the HTTP protocol. I've set up and managed some SVN repositories so feel free to ask for help if you experience problems with the Apache configuration or anything else. That means your repository most probably already supports read AND write access

Marco

[Jeanne Boyarsky]

Marco,
We don't have repository admin privileges so we can't mess with Apache. I think the problem is that we are using the default port of 3690 to connect from the client. Somehow it didn't occur to me that if we can read on 80/8080, we would be able to commit over it as well. As someone who has recently set up Apache elsewhere, this should have been on my mind.

Will try it during the week. I can't test this from home because my computer doesn't block things .

[David Newton]

You could make it so it did :)

[Marco Ehrentreich]

As it was possible to "read" the repository over port 80 it will surely be possible to commit this way too without messing around with Apache. I guess all you have to do is to use repository URLs with the HTTP protocol prefix, i.e. http://your.repository/... instead of svn://your.repository/... as port 3690 is the standard port for the native SVN server daemon which doesn't communicate with HTTP.

Marco

[Jeanne Boyarsky]

David Newton wrote:You could make it so it did :)

Of course I could. But I'm not sure exactly what the problem is. I *think* it is the blocking of the SVN port. But it could be something else. They also block some websites and assorted other things. A better test would be to try it from there the next time I go.

[Marco Ehrentreich]

If they are only blocking non-HTTP ports you could even use nasty tricks like firewall piercing which would allow you to tunnel the native SVN protocol over HTTP

Marco

[Jeanne Boyarsky]

Oh wait. I just realized when one specifies the http/https URL and it uses port 3690, one passes that in the URL. The fact that I don't pass a port in the URL implies it is using the 80/8080 one. I think. There's no harm in explicitly passing 80/8080 to try that though.

Marco: We are using http as the protocol. Now I'm not even sure what is being blocked. I wonder if it is the software rather than the protocol. We'll have to try telnet to see if that gets through from the school.

[Marco Ehrentreich]

That sounds like a strange SVN setup to me. Are you sure that the repository is accessed via HTTP/HTTPS but uses the default port for the SVN native server? But the unusual protocol/port combination would explain why it's very likely that the network traffic just get blocked because of the port. But as you said, a little telnet session should quickly show the problem.

Marco

[Jeanne Boyarsky]

Marco Ehrentreich wrote:That sounds like a strange SVN setup to me. Are you sure that the repository is accessed via HTTP/HTTPS but uses the default port for the SVN native server?

I'm not sure of much of anything. The "rules" seem to be that the magic proxy blocks a lot of things.

I know we access via HTTP and port 80 through the browser. At home, I commit via HTTP at the same URL over port 80. This implies my initial assumption that the port number was the problem is faulty. Something is blocking the commits though.

I still have the problem of how do I get this to look like regular web traffic in a browser though.

[Marco Ehrentreich]

If you're using port 80 at home then it usually should be the same port from your "problem location".

Unfortunately this would mean that this magic proxy is cleverer than a stupid packet filter which only blocks traffic based on port numbers. Everything would be possible in this case. Maybe it inspects not only protocols and ports but even the content in the application layer protocol. Or it only allows for certain HTTP methods like GET or POST but blocks others like PUT and DELETE (which are needed for read-write SVN access as far as I know). I guess then you'd be out of luck if you can't find another way to connect to the outside world or convince the proxy administrator to allow your SVN traffic.

Marco

[Jeanne Boyarsky]

Marco Ehrentreich wrote:I guess then you'd be out of luck if you can't find another way to connect to the outside world or convince the proxy administrator to allow your SVN traffic.

Nuts! I guess we are back to our hodge podge of connectivity. The proxy administrator is the New York City Board of Education. I can say with confidence they aren't going to change things for us!

[Marco Ehrentreich]

I can say with confidence they aren't going to change things for us!

I hate when you are at mercy of people like this. I'd suggest that you do some research with telnet or any other network utility to find out what exactly is going on here, i.e. if ports are silently blocked or if SVN commit traffic to the outside is explicitly prohibited.

A sniffer tool like Wireshark on the computer where you are trying to access SVN would be helpful. This could show if SVN commits are simply ignored or if there's an answer regarding access restrictions from some kind of proxy which is just not reported to you by the SVN client.

When you know some more details just let us know

Marco