Parts of this article has previously been posted in my old blog. It’s being reposted because of its usefulness.
A little over a year ago, I had a problem trying both copying and renaming files in Subversion, giving me the ‘502 Bad Gateway’ message. Trying to Google the problem didn’t help me much, and I don’t think it does to this date either.
The error message was:
svn: Commit failed (details follow):
svn: COPY of testfile.py: 502 Bad Gateway (https://hostname)
My solution to the problem was adding the following lines into my vhost-file, between the <VirtualHost *:443> and the closing </VirtualHost>. (I’ve placed them near the top.)
You must of course change the SSLCertificateFile and SSLCertificateKeyFile variables to reflect your own setup. You must also restart Apache.
I can’t guarantee that this workaround actually will work. But I’ve had good experience with it in two cases. In both cases I’ve run Subversion through Apache 2 web server, using the mod_dav_svn module, on a Linux platform. Also, since I have more than one domain name, the web server was set up with virtual hosts, ssl, proxy and rewrite modules.
According to my original post about this problem, I wrote the following:
I stole this solution from Karl Trygve Kalleberg, who fixed it once, and then later forgot how.
Which, if my mind serves me correct, means that I found it when looking through his old configuration files.
9 thoughts on “Subversion – ‘502 Bad Gateway’ Workaround”
I was battling the same 502 error for years. It turns out all I needed to add to my apache configuration was the SSLEngine On directive…
I had recently moved my SVN installation into a separate vhost from my main SSL host and was wondering what the hell was going on.
way cool. at last a solution to my trauma of years.
Thanks. This tip solved my problem.
Cool, it helped !
Still have to see if the 3 last lines are needed…
Mads: If you try, please let me know. I’m currently not running SVN, but it would be nice to be able to update this post since people still is reading it and finding it useful.
great! thank you!
I’ve found a quite good explanation, plus a simpler solution to this problem:
Also described in Apache documentation of mod_headers.
My setup is the following: I have a default SSL configuration, plus some name virtual hosts under directives, as seems to be your case.
The steps needed for me were just:
1. Activate mod_headers
2. Add the following entry inside my directive:
RequestHeader edit Destination ^https: http: early
This way I do not need to replicate the SSL directives from my default SSL virtual host file.