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.
Stefan
Received on 2009-02-10 12:21:34 CET