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

Re: AuthzSVNAccessFile and collection path syntax

From: Garret Wilson <garret_at_globalmentor.com>
Date: 2005-07-09 05:43:05 CEST

Sander Striker wrote:
Garret Wilson wrote:
I'm wondering why the decision was made to have a path not ending with slash designate a collection (i.e. directory), but to have Subversion not recognize a path ending in a slash?

The decission was quite simple, it made it work as easily as possible.
mod_authz_svn doesn't have access to the repository; it doesn't open it.
Therefor mod_authz_svn doesn't know whether a URI is for a collection or
Well, I could see accepting both, but why deny those URIs ending in '/'? That makes it hard for us anal types who like to be overly consistent...

(In fact, this relates to the reason we have to put BrowserMatch "Microsoft Data Access Internet Publishing Provider" redirect-carefully in our Apache config files:
According to general URI convention and the WebDAV specification, along with several later community discussions, the canonical way to represent a collection is with an ending slash. Technically, there could be two distinct resources, /public and /public/, only the latter of which is a collection. (The former could be a text file, for instance.)

Well, technically it's already in the default httpd config isn't it? :)
Well (continuing my rant), *all* of the following aren't in the default httpd.config:

"^gnome-vfs.*"    //Gnome; see http://bugzilla.gnome.org/show_bug.cgi?id=92908 ; https://bugzilla.redhat.com/beta/show_bug.cgi?id=106290
"Microsoft Data Access Internet Publishing Provider.*"    //http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0190.html
"Microsoft-WebDAV-MiniRedir/5\\.1\\.2600.*"    //http://mailman.lyra.org/pipermail/dav-dev/2003-June/004777.html
"^DAVAccess/1\\.[01234]\\.[1234].*"    //iCal; see http://macintouch.com/panreader02.html
"^Dreamweaver-WebDAV-SCM1\\.0[23].*"    //Dreamweaver MX, 2003; see http://archive.webct.com/docs/mail/nov03/0018.html
"^neon.*"    //neon; see http://archive.webct.com/docs/mail/nov03/0018.html ; http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg53373.html
"^WebDAVFS.*"),    //Macintosh OS X Jaquar; see http://www.askbjoernhansen.com/archives/2002/08/27/000115.html
"^WebDrive.*")    //http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0190.html

Yes, all this @#$! buggy clients don't treat "collection/" and redirects correctly. (My bitterness stems from hours researching these issues writing a WebDAV server from scratch, along with working in the RDF world where URIs actually mean things)

See generally:

http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0190.html (entire thread)

BTW, what does the AuthzSVNAccessFile do when I have both /repos/myresource (text/plain) and /repos/myresource/ (directory), and I want to give separate restrictions on them? (Or does Subversion even allow a directory with the same name as a file?)

The Subversion convention of no trailing slash is also inconsistent with its method of designating a repository root directory. (Consistency would call for using [repos:] as the root designation.)

Yes, but [] looks somewhat wrong doesn't it?  I wonder if it would even count
as a valid config section name.
:) My comment was supposed to illustrate the absurdity of such a thing and advocate consistency in the other direction---ending slashes on all collections, even the root collection.

Of course, this little AuthzSVNAccessFile syntax thing is a terribly tiny thing---I thought I would raise it just to make sure there was an awareness of the issue.

Subversion is awesome!



--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org For additional commands, e-mail: dev-help@subversion.tigris.org Received on Sat Jul 9 05:44:04 2005

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

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