This is not a problem on the server.  As I wrote in my original e-mail, there 
is no network traffic at all between the client and server in the failure case.

I have confirmed this by reproducing the problem when the server has its 
network cable unplugged.   I know what the message is supposed to mean, but the 
client is reporting the wrong error.

After some further experimentation, I have come to the conclusion that it is 
treating the hostname “svn” specially.  The host has another hostname in DNS 
and I can correctly access the server using that name.

Ian Miller

> On 17 Apr 2023, at 21:08, Daniel Sahlberg 
> <daniel.l.sahlberg|subvers...@gmail.com> wrote:
> 
> Den mån 17 apr. 2023 kl 20:20 skrev Ian Miller <subvers...@singularis.ltd.uk 
> <mailto:subvers...@singularis.ltd.uk>>:
> Before reporting this as a bug, I am posting it here as suggested on the “How 
> to report a bug” page.
> 
> After upgrading my O/S to Debian 11, and with it the subversion client to 
> version 1.14.1 (r1886195), I started getting
> the following error whenever I tried to access the server:
> 
> svn: E175003: The server at 'http://svn/singularis/trunk 
> <http://svn/singularis/trunk>' does not support the HTTP/DAV protocol
> 
> I checked to see what the network traffic associated with this and found that 
> there was none.  I get the same error attempting make a new checkout.  
> However if I substitute the server’s IP address into the URI it works.
> It also works with a FQDN.   It seems that it failing resolve the hostname.   
> Everything else on the host seems to be able to resolve the hostname.  
> /etc/resolv.conf seems to be correct.
> 
> It is conceivable that there is a DNS resolver problem.  However the error 
> message being produced is completely wrong and grossly misleading.
> 
> The error message basically means that the URL supplied by the client isn't 
> an SVNPath in the server conf.
> 
> Could it be that the HTTPD configuration has several virtual hosts where the 
> ServerName "svn" is handled by another virtual host compared to the FQDN?
> 
> Kind regards,
> Daniel

Reply via email to