I realize that I'm not Greg, but I know a little something about this, so
I thought I would take a stab at offering a solution. :-) If I have time,
I'll try to create a patch too.
The problem is how mod_dav is handling the COPY command, and the bug is
likely going to need to be fixed in mod_dav. The problem is that mod_dav
is assuming that the URL that it receives is the same one that the user
typed in, which is likely to not be the case if the server is behind a
proxy.
The best thing to do would be to have mod_dav somehow make a
request for the URL in the Destination header to find the local
destination. But, that would be a somewhat scary hole to open up on the
server.
So instead, mod_dav is going to need to provide a directive somewhat
analagous to alias. Essentially allowing mod_dav to rewrite a
Destination header to remove proxy information. Something along the lines
of:
DAVAlias https://www.foo.com/ http://www.foo.com/
This would change all Destination headers from https://www.foo.com/... to
http://www.foo.com/...
Ryan
On Tue, 26 Aug 2003, Jason Vasquez wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On 26 Aug 2003, Ben Collins-Sussman wrote:
> > > ServerAlias, etc.) -- unfortunately, that doesn't really apply here, since
> > > the URI scheme (not just the hostname) is different.
> >
> > Can you be more specific? Give more context? Point to discussion threads?
>
> In this particular scenario, the web server that the client sees is
> accessible via https. In fact, this is a reverse/transparent/etc proxy,
> that is funneling request back to an actual Apache server that is NOT
> running ssl. The COPY command from the client is supplying a Destination
> header of https://.../ (which the proxy does not modify). Apache/DAV/SVN
> is expecting to see a Destination in the form of http://.../. It appears
> to be bombing since the schemes differ (although the rest of the URL path
> will be the same)
>
> I see several possible solutions here:
>
> 1. Do something in the svn client to have a special case to specify a
> Destination "root" for particular hosts
>
> 2. Have the proxy modify the Destination header before passing it back
> to the backend server.
>
> 3. Make mod_svn/dav/whatever not care if the scheme is different
> (although, this sounds like it breaks spec, and is not very portable
> to the ServerAlias/ServerName problem)
>
> Hmm - now that I think about it, option 3 might in fact work well, if
> there are some additional Apache config directives to add additional
> allowable Destination URI's for a SVN root.
>
> I believe that this thread (that you started :)) refers to the same
> situation, only in that case it had to do with Apache ServerNames:
> http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=44701
>
> I haven't seen anything yet related to a difference in the request URI
> scheme.
>
>
> > I don't understand how this scenario happened: how is it possible for
> > your svn client to generate an http:// COPY request with a destination
> > header to an https:// url?
> (hopefully the above discussion explains this)
>
> - --
> - -------------------------------------------------------------------
> | | |
> | Jason Vasquez | When their numbers dwindled from |
> | jason@obiwan.homelinux.org | 50 to 8, the other dwarves began |
> | http://obiwan.homelinux.org | to suspect Hungry. |
> | | |
> |------------------------------------------------------------------
> | Public Key: http://obiwan.homelinux.org/~jason/pubkey.txt |
> - -------------------------------------------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
>
> iD8DBQE/S6K6Y6zA1HI6auYRAi+0AJsFFiceGajcHK9ZqFZTwNL576ugjgCgmbbO
> XbRgxuz1qrOiFhEj+BJwsgA=
> =c2Jw
> -----END PGP SIGNATURE-----
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 26 22:06:46 2003