Hi Hannes,
Maybe you need to include OPTIONS in your httpd.conf, try this:
# Limit write permission to list of valid users.
<LimitExcept GET PROPFIND OPTIONS REPORT>
AuthType Basic
AuthName "Subversion"
AuthUserFile /svn/authfiles/svn-htpasswd
AuthzSVNAccessFile /svn/authfiles/svn-access.conf
Require valid-user
</LimitExcept>
2009/1/8 Hannes Erven <h.e_at_gmx.at>
> Hi list,
>
>
> I am experiencing a strange problem with svn up after svn cp in a
> subdirectory: svn does a HTTP OPTIONS request directly on the repository
> root, which is forbidden due to the authz config and hence the svn up
> fails.
> Surprisingly, there is no error when using svn up -r REV to step up the
> revisions one by one, so I suppose this might be a hidden feature (or
> problem :-] ).
>
> It looks to me that http://svn.haxx.se/users/archive-2008-04/0579.shtml
> might be the same issue, but I don't do fancy imports so it might well
> be something completely different...
>
>
> So here's the story: the repository is served over https:// by 1.5.2
> (r32768, Gentoo) to a 1.5.4 (r33841, Gentoo) client. The authz config on
> the server looks like this (irrelevant sections stripped):
>
> [/]
> svnroot = rw
> * =
>
> [/Folder1/Folder2]
> svnroot = rw
> user = rw
> * =
>
> (There is no section for Folder1 or for subfolders of Folder2)
>
>
> And now watch this (authenticating as "user"):
>
>
> $ svn co $REPO/Folder1/Folder2/svn-test
> Checked out revision 4415.
> # (Empty folder, but doesn't matter)
>
> $ touch foo.txt
> $ svn add foo.txt
> $ svn commit -m "SVNTEST"
> Adding foo.txt
> Transmitting file data .
> Committed revision 4416.
>
> $ svn cp foo.txt bar.txt
> $ svn commit -m "SVNTEST"
> Adding bar.txt
> Committed revision 4417.
>
>
> So now we're set up. On another machine, this user had a working copy at
> revision 4415 and wanted to svn up, but got 403 Forbidden.
> The problem can also be reproduced at the very same wc, so lets
> downgrade to 4415 (before the svn cp):
>
> $ svn up -r 4415
> D foo.txt
> D bar.txt
> Updated to revision 4415.
>
>
> And this is where the strange things start: lets simply svn up :
>
> $ svn up
> A foo.txt
> svn: Server sent unexpected return value (403 Forbidden) in response to
> OPTIONS request for '$REPO'
>
> The server log contains:
>
> Access denied: 'user' OPTIONS svn:/
> Provider encountered an error while streaming a REPORT response. [500,#0]
> A failure occurred while driving the update report editor [500, #104]
> Error writing base64 data: Connection reset by peer [500, #104]
>
>
>
> But, stepping up one by one does not produce this error:
>
> # Restore the wc to the rev before the problem
> $ svn up -r 4415
> D foo.txt
> Updated to revision 4415.
>
> $ svn up -r 4416
> A foo.txt
> Updated to revision 4416.
>
> $ svn up -r 4417
> A bar.txt
> Updated to revision 4417.
>
>
> And now regular svn up works as well:
> $ svn up
> At revision 4417.
>
>
>
> If I grant read access on / to this user, the 403 goes away. Is this by
> design? Why is the OPTIONS on / needed anyways?
>
> Should I write a reproduction script and test whether this issue exists
> on an svnserve'd repo as well?
>
>
> Thanks for your help,
>
> -hannes
>
> ------------------------------------------------------
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1012038
>
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe_at_subversion.tigris.org].
>
Received on 2009-01-08 19:17:02 CET