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
Stefan
Received on 2009-02-10 14:02:06 CET