[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[PATCH] svn_ra_dav__get_lock fails through re-writing proxy

From: Rich Williams <perldog_at_gmail.com>
Date: 2006-09-18 12:29:02 CEST


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

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

Received on Mon Sep 18 12:29:18 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.