[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Issues with an authz-protected repository

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 10 Feb 2009 11:13:28 +0000

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?

1.5 has similar code in libsvn_ra_neon/session.c:exchange_capabilities().

Looks like 1.4 did not do this capabilities exchange.

Basically, if this explains the problem, then denying access to the repository
root via authz cannot be done in 1.5 because of the way the capabilities exchange
has been implemented.


> ...
> OPTIONS /usr HTTP/1.1
> Host: svn.plt-scheme.org
> User-Agent: SVN/1.5.5 (r34862) neon/0.25.5
> ...
> Authorization: xxxxxxxxxxxxxx...
> [status-line] < HTTP/1.1 403 Forbidden
> This is with both client and server at 1.5.5.
> Is this a bug?
> --
> ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
> http://www.barzilay.org/ Maze is Life!
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1131969
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-10 12:14:33 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.