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

Re: strange error with subversion: "client denied by server configuration: /htdocs"

From: John Pye <john.pye_at_anu.edu.au>
Date: Thu, 21 May 2009 14:40:13 +1000

Hi all

Andrey Repin wrote:
> Greetings, John Pye!
>
>
>>>>> Looking at your VH definition... it's messy.
>>>>> Reduce the number of entities. Add next one only after you have the previous
>>>>> work "as expected".
>>>>> And put
>>>>>
>>>>> Order allow,deny
>>>>> Allow from all
>>>>>
>>>>> Before <Location> blocks.
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>> You can't put Order or Allow statements outside either <Location> or
>>>> <Directory> tags, AIUI.
>>>>
>>>>
>>> Still, it's messy.
>>>
>>> Try starting from
>>>
>>> <VirtualHost *:80>
>>> ServerAdmin john.pye_at_anu.edu.au
>>> ServerName ascendsvn.cheme.cmu.edu
>>>
>>> DocumentRoot /var/www/svn
>>>
>>> # Possible values include: debug, info, notice, warn, error, crit,
>>> # alert, emerg.
>>> LogLevel debug
>>> ErrorLog /var/log/apache2/svn-error.log
>>>
>>> RedirectMatch ^/stats/?$ http://ascend.cheme.cmu.edu/awstats/awstats.pl?config=ascendsvn.cheme.cmu.edu
>>>
>>> #RedirectMatch permanent ^/$ /ascend
>>>
>>> CustomLog /var/log/apache2/svn.log combined
>>> ServerSignature On
>>>
>>> <Location />
>>> Order Allow,Deny
>>> Allow from all
>>> DAV svn
>>> SVNParentPath /home/svn
>>> </Location>
>>>
>>> </VirtualHost>
>>>
>>> And see how that would work.
>>>
>>>
>
>
>> I tried this, I get exactly the same error message. svn-error.log
>> contains...
>>
>
>
>> [Tue May 19 19:35:42 2009] [error] [client 128.2.52.249] client denied
>> by server configuration: /var/www/svn/ascend
>>
>
>
>> This error is completely weird because it relates to
>> /var/www/svn/ascend, which doesn't exist and should NEVER be being
>> requested...
>>
>
> Hm. Try setting
> DocumentRoot /home/svn
> ?
>

That can't possibly be the solution. The directory structure of
/home/svn in no way matches the paths that are being requested via the
URLs, so this is definitely not the solution.

>> I appreciate your general approach but as far as I can see we're not
>> touching the root cause of this problem yet.
>>
>
> Well, two things I know may produce this result:
> Location/Directory block referencing the path requested and the general
> Allow/Deny rule over the "/" of filesystem.
> It's really hard to tell what is the case by looking only at the extracted
> part of Apache configuration.
>

I don't actually think that this is an Allow/Deny problem.

If I create the /var/www/svn/ascend/code/trunk/

Let's focus on this PROPFIND request. The error message always relates
to a PROPFIND request. Why is that request being issued? Is it possible
some on some machines that request is not being issued, because of
something that's been cached in the system? Or is the PROPFIND request
being made successfully in some cases, and not in others.

My request:

root_at_ascend:~# svn co
http://ascendsvn.cheme.cmu.edu/ascend/web/trunk/ascend_html test1
svn: PROPFIND request failed on '/ascend/web/trunk/ascend_html'
svn: PROPFIND of '/ascend/web/trunk/ascend_html': 403 Forbidden
(http://ascendsvn.cheme.cmu.edu)

Output to svn.log:

128.2.52.249 - - [20/May/2009:23:02:23 -0400] "PROPFIND
/ascend/web/trunk/ascend_html HTTP/1.1" 207 714 "-" "SVN/1.4.6 (r28521)
neon/0.27.2"
128.2.52.249 - - [20/May/2009:23:02:23 -0400] "PROPFIND
/ascend/!svn/vcc/default HTTP/1.1" 207 397 "-" "SVN/1.4.6 (r28521)
neon/0.27.2"
128.2.52.249 - - [20/May/2009:23:02:23 -0400] "PROPFIND
/ascend/!svn/bln/2280 HTTP/1.1" 207 454 "-" "SVN/1.4.6 (r28521) neon/0.27.2"
128.2.52.249 - - [20/May/2009:23:02:23 -0400] "PROPFIND
/ascend/web/trunk/ascend_html HTTP/1.1" 207 714 "-" "SVN/1.4.6 (r28521)
neon/0.27.2"
128.2.52.249 - - [20/May/2009:23:02:23 -0400] "PROPFIND
/ascend/!svn/vcc/default HTTP/1.1" 207 397 "-" "SVN/1.4.6 (r28521)
neon/0.27.2"
128.2.52.249 - - [20/May/2009:23:02:23 -0400] "PROPFIND
/ascend/!svn/bln/2280 HTTP/1.1" 207 454 "-" "SVN/1.4.6 (r28521) neon/0.27.2"
128.2.52.249 - - [20/May/2009:23:02:23 -0400] "PROPFIND
/ascend/web/trunk/ascend_html HTTP/1.1" 207 714 "-" "SVN/1.4.6 (r28521)
neon/0.27.2"
128.2.52.249 - - [20/May/2009:23:02:23 -0400] "PROPFIND
/ascend/!svn/vcc/default HTTP/1.1" 207 397 "-" "SVN/1.4.6 (r28521)
neon/0.27.2"
128.2.52.249 - - [20/May/2009:23:02:23 -0400] "PROPFIND
/ascend/!svn/bln/2280 HTTP/1.1" 207 454 "-" "SVN/1.4.6 (r28521) neon/0.27.2"
128.2.52.249 - - [20/May/2009:23:02:23 -0400] "PROPFIND
/ascend/web/trunk/ascend_html HTTP/1.1" 403 403 "-" "SVN/1.4.6 (r28521)
neon/0.27.2"

Output to svn-error.log:
[Wed May 20 23:02:23 2009] [error] [client 128.2.52.249] client denied
by server configuration: /var/www/svn/ascend

Everything seems to be going OK until the final request, which returns
the "unauthorised" 403 response.

I'm not clear why several very similar requests seem to be being made,
eg "PROPFIND [...]/bln/2280" -- is that normal?

The final error message from svn-error.log makes no sense, because the
'ascendsvn' virtual host is obviously dealing with it, but DAV is
apparently not dealing with it, even though the URL seems to match.
Also, why is it a 403 error, rather than a 404 error, given that there
is no such directory /var/ww/svn/ascend.

To try an keep SVN happy, I did an experiment:

cd /var/www/svn
mkdir -p ascend/code/trunk/solvers

Now, this has a *very interesting result*:

On all client machines (both the ones that were previously broken and
the ones that were previously working) I get:

svn co http://ascendsvn.cheme.cmu.edu/ascend/code/trunk/solvers/ test23
svn: Repository moved permanently to
'http://ascendsvn.cheme.cmu.edu/ascend/code/trunk/solvers/'; please relocate

(notice the pointless message: the URLs are equal)

If I remove the DocumentRoot directive then the machines that were
previously working continue to work, and the machines that were
previously broken go back to the same 403 error again.

Then, I tried performing the PROPFIND request using telnet:

root_at_ascend:~# telnet ascendsvn.cheme.cmu.edu 80Trying 128.2.52.249...
Connected to ASCENDSERVER.cheme.cmu.edu.
Escape character is '^]'.
PROPFIND /ascend/code/trunk/solvers/ HTTP/1.1
Host: ascendsvn.cheme.cmu.edu
User-Agent: JohnPye

HTTP/1.1 403 Forbidden
Date: Thu, 21 May 2009 03:21:15 GMT
Server: Apache/2.2.8 (Ubuntu) DAV/2 SVN/1.4.6 PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g
Content-Length: 417
Content-Type: text/html; charset=ISO-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>PROPFIND requests with a Depth of "infinity" are not allowed for /ascend/code/trunk/solvers/.</p>
<hr />
<address>Apache/2.2.8 (Ubuntu) DAV/2 SVN/1.4.6 PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g Server at ascendsvn.cheme.cmu.edu Port 80</address>
</body></html>

Isn't that exciting!

Any thoughts?

>
>> And I am still baffled as to why I could see this problem on some
>> machines, but not on others. We need to understand what things can vary
>> from machine to machine to cause this problem to occur.
>>
>
> If you change your problematic machine IP to one which does not experience
> this problem, does it get to work?
>

The problem is not a straight-forward issue about IP address-based
limitations. For example, as user 'root' on the repository host machine,
I have a checked-out repository on which I can do an "svn up" and "svn
ci" with no problems, but as the same user, I can not check out a new
working copy using "svn co". If it's an IP-based thing, then it's only
some of the time.

Cheers
JP

-- 
Dr John Pye
Dept of Engineering
Australian National University
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2341989
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-21 08:27:38 CEST

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

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