On Tue, Feb 10, 2009 at 8:01 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Tue, Feb 10, 2009 at 11:20:41AM +0000, Stefan Sperling wrote:
>> On Tue, Feb 10, 2009 at 11:13:28AM +0000, Stefan Sperling wrote:
>> > On Mon, Feb 09, 2009 at 10:34:25PM -0500, Eli Barzilay wrote:
>> > > [Apologies if this is a known issue, I've tried too look around for
>> > > this for some time now and didn't see anything.]
>> > >
>> > > We have a private user repository, protected by an authz configuration
>> > > file. Some people have encountered a problem where things die with an
>> > > obscure
>> > >
>> > > svn: Server sent unexpected return value (403 Forbidden) in response
>> > > to OPTIONS request for 'http://svn.plt-scheme.org/usr'
>> > >
>> > > Now, as far as I can tell, this is correct for our setup, since /usr
>> > > is the repository root which is not supposed to be readable, and
>> > > /usr/foo would be the directory for `foo'. We've managed to find a
>> > > way to reproduce this which looks like the following:
>> > >
>> > > svn co http://svn.plt-scheme.org/usr/foo A
>> > > svn co http://svn.plt-scheme.org/usr/foo B
>> > > cd A
>> > > touch blah1
>> > > svn add blah1
>> > > svn ci -m ''
>> > > svn mv blah1 blah2
>> > > svn ci -m ''
>> > > cd ../B
>> > > svn up
>> > > <<403-error>>
>> > >
>> > > After some tweaking of my ~/.subversion/servers, I've managed to get
>> > > some verbose output -- and it looks like the problem happens when it
>> > > tries to get the new "blah2" file -- the output has
>> > >
>> > > <D:checked-in><D:href>/usr/!svn/ver/20822/foo/blah2</D:href></D:checked-in>
>> > >
>> > > and then it immediately proceeds to perform the offending OPTIONS:
>> > >
>> > > HTTP session to http://svn.plt-scheme.org:80 begins.
>> > > HTTP session to http://svn.plt-scheme.org:80 begins.
>> > > Doing DNS lookup on svn.plt-scheme.org...
>> > > Running pre_send hooks
>> > > compress: Initialization.
>> > > Sending request headers:
>> > > OPTIONS /usr HTTP/1.1
>> > > Host: svn.plt-scheme.org
>> > > User-Agent: SVN/1.5.5 (r34862) neon/0.25.5
>> > > ...
>> > > [status-line] < HTTP/1.1 401 Authorization Required
>> >
>> > Could this be normal behaviour because the client is asking the server
>> > about capabilities?
>> >
>> > In trunk, looking at libsvn_ra_neon:svn_ra_neon__exchange_capabilities(),
>> > it passes ras->url->data to svn_ra_neon__request_create(), which has this
>> > code at the top:
>> >
>> > /* We never want to send Neon an absolute URL, since that can cause
>> > problems with some servers (for example, those that may be accessed
>> > using different server names from different locations, or those that
>> > want to rewrite the incoming URL). If the URL passed in is absolute,
>> > convert it to a path-absolute relative URL. */
>> > const char *path = path_from_url(url);
>> >
>> > Could this be where "svn.plt-scheme.org/usr" is converted to just "/usr",
>> > causing incompatibility with the configured authz scheme?
>>
>> That could have been worded better: I didn't mean to say that translating the
>> URL this way causes the problem. The cause of the problem would of
>> course be that we're asking about capabilities at the repository root
>> in the first place.
>
> See also http://subversion.tigris.org/issues/show_bug.cgi?id=3242
I think that issue is specific to the copy command though. In 1.5 it
was changed so that it "anchors" the session at the common parent of
the resources. IMO, this has caused an authz regression and we should
fix it. However, I am not sure it applies here since copy is not
being used.
In the case of the OPTIONS request, does authz even look at that? If
so, why wouldn't it just approve the request if you successfully
authenticate? I cannot see why you would need read access to root to
answer this request.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1134185
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-10 14:42:55 CET