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

Re: MOD_DAV_SVN + SVNSERVE_WRAPPER + file system rights

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Sat, 23 Nov 2013 01:20:16 +0200

Ben Reser wrote on Fri, Nov 22, 2013 at 15:16:10 -0800:
> On 11/22/13 2:56 PM, Daniel Shahaf wrote:
> > Might not be a bad idea then to make the artificial/invalid
> > request_rec.filename value look less like a URL then? Just in case it
> > ends up in someone's "(gdb) p" output, or in a log file, etc.
> >
> > For example, "svn+invalid:/usr/local/svn/ppt/trunk".
>
> My primary goal was to make it unlikely to appear as though it was an actual
> path on the local file system since it really isn't. This is also following a
> similar pattern in Apache httpd that the proxy module uses where it prefixes
> the URLs it's proxying to in r->filename as proxy:
>
> The lack of the extra slash "svn:/" vs "svn://" should be enough to signal it
> isn't a URL.
>
> I'd be concerned that "svn+invalid:" would imply to people there is something
> invalid about the path.
>
> Ultimately I don't think whatever we put in there is going to make everyone
> happy. But since quite a few modules crash if r->filename is NULL we had to
> put something in there, might as well make it somewhat useful.

How about "dav_svn:/" then? That's consistent with mod_proxy's
precedent you cite and not similarly-confusing to the "svn://" URL
scheme.
Received on 2013-11-23 00:20:55 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.