On 9/18/06, Rich Williams <perldog@gmail.com> wrote:
> 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.
Nope, this is perfectly correct. For what it's worth though, I had
your message sitting in my inbox, I just hadn't gotten around to
looking at it closely. I probably would have looked a bit more
quickly if I'd realized it came with a patch though ;-)
> 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.
This analysis seems spot-on to me. I've committed a slightly tweaked
version of your patch in r21526, and will propose it for backport to
1.4.x.
Thanks,
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 18 17:25:36 2006