svn info fails through re-writing proxy

[Rich Williams <pe...@gmail.com>]

Hello,

I realise that our setup is a little unusual, but I think I've found a bug
and I've got a patch for it.

In our setup, some clients access the repository over https, but through a
different host which proxies the request (it's not configured as a proxy
server - it's Apache with mod_rewrite/mod_proxy). We're not changing the
path (although we tried it at first, that seemed to be a non-starter) but
we are (obviously) changing the host name.

The apache config on the proxying host (I'll call it 'proxy-svn-host')
includes a line like this...

RewriteRule ^/svn(/.*)? https://real-svn-host/svn$1 [P]

For the most part, this works flawlessly, except for one operation -
'svn info' when given a url. i.e. 'svn info https://proxy-svn-host/svn/'
which fails with "svn: Failed to fetch lock information: 404 Not Found"

Turning on some neon debug, and looking at the logs on the proxying
and real svn hosts, there are plenty of PROPFINDs on urls like /svn/,
/svn/!svn/vcc/default etc, and then when it gets to the final stage,
it does 'PROPFIND https://proxy-svn-host/svn/ HTTP/1.1' - when all the
other requests have not included the scheme+hostname in the HTTP
request line.

Using gdb, I tracked this down to the call to 'ne_lock_discover' in
'svn_ra_dav__get_lock'. I tweaked the source at this point to strip
off the scheme+host (using ne_uri_parse), and now everything works
just fine.

I don't really know enough about DAV to know if it's valid to include
the host+scheme in a request or not, but it felt like a bug to me.

I've attached my patch.

Have fun,

Rich Williams