OK perhaps your SSL accelerator introduces another issue there. I know
from having investigated this same problem with an Apache/reverse proxy
configuration, that running SVN over a reverse proxy in and of itself
works fine. The problem with running an HTTPS -> HTTP reverse proxy was
that the reverse proxy mapping (to modify the external HTTPS request URL
to the internal HTTP 'format') would happen BEFORE the SSL decrypt, so
that mod_proxy never got to see the other URL (the one in the encrypted
portion of the request). Theoretically, if the SSL decrypt were to
happen BEFORE the processing of the proxy directives, mod_proxy would
work off the decrypted request and see both URLs.
Hope that made sense.
Cheers
Rob
________________________________
From: LANDRAIN Jean-Pol [mailto:jplandrain@europarl.eu.int]
Sent: Monday, March 13, 2006 9:56 AM
To: users@subversion.tigris.org
Subject: RE: RE: svn COPY 502 bad gateway over HTTPS
It's not exactly the problem. I'll resume it to help you understand what
happens (at least, up to what I understand so far):
The SVN branch/tag command uses the WebDAV COPY command. The source
parameter for this command is the URL of the request. The target
parameter can be found in the header of the request (a full url,
absolute path, because the DAV protocol requires it).
In our environment (like in a lot of other companies), Apache is not
configured to understand HTTPS. Some hardware or software bridge(*)
decrypts the HTTPS requests, transforming them into normal HTTP request,
before calling Apache and encrypts the responses before sending them
back to the clients. The problem is that these "bridges" modify only the
URL of the requests (the source URL in the case of our COPY command) and
not the URL(s) in the header of the requests (the target URL in the case
of our COPY command).
So, to resume, if you have a command like(**)
DAV COPY from https://www.host.name/src/dir to
https://www.host.name/target/dir
This command becomes after transformation:
DAV COPY from http://www.host.name/src/dir
<http://www.host.name/src/dir> to https://www.host.name/target/dir
<https://www.host.name/target/dir>
Instead of:
DAV COPY from http://www.host.name/src/dir
<http://www.host.name/src/dir> to http://www.host.name/target/dir
<http://www.host.name/target/dir>
The problem is that the Apache WebDAV module checks the two schemes and
ports are the same before it executes the command.
(*) an SSL accelerator in our case, but it can be a reverse proxy or
another Apache server.
(**) The actual commands are not like this, of course. This is to help
you understand what's happening.
Best Regards,
Jean-Pol.
________________________________
From: Rob van Oostrum [mailto:rob.vanoostrum@blastradius.com]
Sent: 13 March 2006 15:17
To: LANDRAIN Jean-Pol; users@subversion.tigris.org
Subject: RE: RE: svn COPY 502 bad gateway over HTTPS
Theoretically, the solution would be for Apache to SSL-decrypt
the request before applying the proxy rules. I don't know enough about
Apache or mod_ssl to understand why this wasn't implemented this way
from the outset.
Cheers
Rob
________________________________
From: LANDRAIN Jean-Pol [mailto:jplandrain@europarl.eu.int]
Sent: Monday, March 13, 2006 8:30 AM
To: users@subversion.tigris.org
Subject: RE: svn COPY 502 bad gateway over HTTPS
I've found an old discussion about this issue:
http://svn.haxx.se/users/archive-2003-08/0763.shtml
I have done some tests with one of our network admins and it is
exactly the situation we have here.
As SVN is being adopted by more and more companies, the problem
will come out more and more often. I understand this is not a problem of
SVN or the Apache DAV module, but 3 years later maybe it's time to find
a solution, even if you don't like it. Isn't it ?
Best Regards,
Jean-Pol.
________________________________
From: LANDRAIN Jean-Pol
Sent: 13 March 2006 12:06
To: 'users@subversion.tigris.org'
Subject: svn COPY 502 bad gateway over HTTPS
Hello,
My company is using SVN for a few months on a pilot
project (we've been using CVS before and would like to migrate to SVN,
but we must be sure this can be done smoothly). We have now decided to
use it over HTTPs to open it to our external developers. Unfortunately,
we're blocked on a weird (but known) problem: the "svn COPY 502 bad
gateway over HTTPS" problem.
Searching on google and in the svn mailing lists, I've
seen different explanations and solutions (or workarounds) for it, but I
can't decide which one is the correct one and will work for us. We'd
like to find an easy solution, but it doesn't look like this exists.
We're a bit lost with the amount of (often unclear for the novice)
information. If someone could explain us clearly what is the problem (it
looks like it is the mod_dav module in Apache that uses absolute urls
instead of relative ones. Right ? Is it a problem only when using a
reverse proxy over https ?) and how to fix it, that would be really
kind.
Best Regards,
Jean-Pol.
Received on Mon Mar 13 16:39:34 2006