Vincent Lefevre <vincent-...@vinc17.net> writes: > On 2014-02-14 18:34:52 +0000, Philip Martin wrote: >> Vincent Lefevre <vincent-...@vinc17.net> writes: >> >> > With svn 1.8.5 under GNU/Linux (Debian unstable), I get an error >> > >> > svn: E175013: Access to '/svn/xxxx' forbidden >> > >> > when I do "svn diff -r118:119 https://host/xxxx/subdir";, but >> > "svn diff -r118:119 https://host/xxxx/subdir/file"; is OK. >> > >> > There's no such problem with svn 1.6.12 (r955767) on some other >> > Debian machine and svn 1.7.9 (r1462340) on an Ubuntu machine. > [...] >> A network trace would help, but I've never had much success getting >> wireshark to decode an https conection even when I have access to the >> server. It might be easier to use a debug version of the client to >> determine which request is failing. > > Anyway since the error message is > > Access to '/svn/xxxx' forbidden > > doesn't it mean that it tries to do an access to '/svn/xxxx'? > If it does, then that's the bug. Access to '/svn/xxxx' is really > forbidden and should not be needed (and it wasn't with the older > svn clients).
I don't know why the client would send such a request. You might be able to use socat to debug the traffic. Run a socat relay on the client machine, something like: socat -v TCP-LISTEN:9630,reuseaddr,fork OPENSSL:svn.apache.org:443,verify=0 then run the client command, something like: svn ls http://localhost:9630/repos/asf/subversion and socat should dump the decoded SSL traffic. You may have to use TCP6-LISTEN if the client cannot connect. Disabling compression with --config-option servers:global:http-compression=no makes it easier to see the body of the response. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
