Hi Ryan
Ryan Schmidt wrote:
> 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.
Perhaps those guys could be persuaded to redirect to the newer book?
>> 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.
It's a quote! Seems ridiculous to me that DocumentRoot should even enter
into a discussion on configuring a SVN-over-WebDAV server.
>>> 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.
I couldn't see any...
jpye_at_ascend:/etc/apache2$ sudo find . | sudo xargs grep "Deny"
./mods-enabled/status.conf: Deny from all
./sites-enabled/000-default: Deny from all
./apache2.conf: Deny from all
In apache2.conf, it's a rule for .ht* files.
In status.conf, it's a rule for the location /server-status
In default, it's a rule for directory /var/www and another for
/usr/lib/cgi-bin.
That's all the files being read as far as I can tell. Some others in
'sites-available' and 'mods-available' that shouldn't be read.
>
>>> 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.
I think I tried that, wasn't the solution.
>
>
>>> 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.
Point is that this was working most of the time, just failing sometimes.
>> 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.
I could even attempt the exact same query and sometimes it would fail
then try again and it would work. Something about local caching maybe?
Anyway, happily migrated to svnserve now. Hopefully it will be problem free.
Cheers
JP
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2358682
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-02 17:12:54 CEST