On May 26, 2009, at 00:03, John Pye wrote:
>>>> Hm. Try setting DocumentRoot /home/svn?
>>>
>>> That can't possibly be the solution.
>>
>> To me, it absolutely must.
>
> I note that most SVN configurations work fine with no DocumentRoot
> being
> specified.
> http://svnbook.red-bean.com/en/1.1/ch06s04.html
Note that this is the ancient 1.1 version of the book. A newer 1.5
version of the book exists.
> http://articles.techrepublic.com.com/5100-10878_11-5902186.html
> http://www.debuntu.org/2006/05/20/54-how-to-subversion-svn-with-
> apache2-and-dav
>
>
> To quote the red bean book:
>
> For example, if your main DocumentRoot is /www, do not export a
> Subversion repository in <Location /www/repos>. If a request comes in
> for the URI /www/repos/foo.c, Apache won't know whether to look for a
> file repos/foo.c in the DocumentRoot, or whether to delegate
> *mod_dav_svn* to return foo.c from the Subversion repository.
Is that passage really in the book too? I know it's in the FAQ. I
have often lamented the fact that the author of that paragraph
appears not to understand the difference between URL paths and disk
paths. Clearly if DocumentRoot is /www then any URL path will be
appended to /www to get its disk path. So a request for the URI /www/
repos/foo.c might attempt to access the disk file /www/www/repos/
foo.c. But it will not look for a disk file /www/repos/foo.c as the
paragraph states.
>> The only way to cause "Client denied by server configuration" is
>> to have
>> implicit or explicit Deny rule applied to that client in one way
>> or another.
>
> OK, so it's possible, but I'm still hunting for where this could be.
> Unless it's in one of the /etc/apache2/mods-available files...
>
> Surely my configuration file overrides any such Allow/Deny rules, by
> creating a whole new set?
Well, if you have a global Allow or Deny rule set somewhere, then it
applies globally.
>> Which leads to what i though: you have globally defined settings that
>> affecting your virtualhost.
>> Either Option -Indexes or Deny
>
> Surely I can override there here though? Surely I already have with
> the
> settings previously provided? If not, how not?
If there is a global Options directive elsewhere that is causing
interference (I don't know that an Options directive can cause
interference to Subversion), then you can define a new Options
directive for the Subversion repository area to set the options back
to defaults maybe.
>> Hm. This is interesting. I've tried this same request on my repos.
>>
>> curl -iX PROPFIND -u user:pass http://svn.darkdragon/repos/trunk
>> HTTP/1.1 403 Forbidden
>> Date: Thu, 21 May 2009 12:14:29 GMT
>> Server: Apache/2.2.11 (Win32) mod_auth_sspi/1.0.5 SVN/1.6.1 PHP/
>> 5.2.2 DAV/2
>> Content-Length: 227
>> 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 /repos/trunk.</p>
>> </body></html>
>>
>> Client was running 1.6.1 too.
>
> OK, so you're getting the "Depth infinity" error as well... so a 403
> error is a fundamental part of a fully operations SVN installation???
I think he's trying to show, since the same error message occurs when
he runs the command against his working repository, that the error
message is inconsequential. I would imagine you need to add more
parameters to the PROPFIND command in order to make Subversion return
an intelligible result.
> An interesting thing, not sure if it's relevant. Today I attempted an
> "svn up" on my *working* client, and I got the 403 error once, then
> got
> a successful update the second time!
>
> john_at_thunder:~/ascend$ svn up
> svn: Server sent unexpected return value (403 Forbidden) in
> response to
> PROPFIND request for '/ascend/code/trunk'
> john_at_thunder:~/ascend$ svn up
> At revision 2280.
>
> How could that happen?
More intermittent behavior, as if sometimes Apache is reaching for
one resource (which is 403 forbidden) and sometimes it's reaching for
a different one (which is your repository). I don't know if I have
any other tricks to suggest for how to identify the conflicting
directives in your config file.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2358669
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-02 09:34:16 CEST