403 Forbidden in response to OPTIONS after svn cp with authz

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 18:44:58 CET