[PATCH] svn_ra_dav__get_lock fails through re-writing proxy

Hello,

I sent this to users@ about 10 days ago, but since then 1.4.0 was
released, so I suspect it got lost/overlooked. Apologies if resending
it to dev@ is bad form, but I'm not really sure what else to do.

I think I've found a bug which causes svn info to fail (in admittedly
a non-standard configuration). In our setup, all clients access the
repository over https, but some clients access it through a second
host which proxies the request for them. It's not configured as a
proxy server - it's Apache with mod_rewrite/mod_proxy. 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', which fails -
the proxying host responds with a 404, because it hasn't matched the
RewriteRule (I tried various extra rules to catch this, but failed).
All the other requests do not include the scheme+host in the HTTP
request line and go through just fine.

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. As far as I can tell, this change doesn't break anything
else.

I don't really know enough about DAV to know if it's valid to include
the schema+host in a request or not, but given that it works just
fine without it, it feels like a bug to me.

The attached patch is against 1.3.2, but the same problem occurred
when I tried it with 1.4.0. Please consider incorporating this fix (or
something like it) - at the moment we're having to patch all our
client installations to work around this issue.

Have fun,

Rich Williams

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org