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

Re: svn commit: r1614080 - in /subversion/branches/authzperf: BRANCH-README subversion/libsvn_repos/authz.c subversion/libsvn_subr/config.c subversion/libsvn_subr/config_impl.h

From: Branko Čibej <brane_at_wandisco.com>
Date: Tue, 29 Jul 2014 13:05:45 +0200

On 29.07.2014 12:55, Johan Corveleyn wrote:
> On Tue, Jul 29, 2014 at 12:46 PM, Branko Čibej <brane_at_wandisco.com> wrote:
>> On 29.07.2014 12:25, Julian Foad wrote:
>> Brane wrote:
>> if the patterns were:
>> [*/projects/f*/include/*.h]
>> [*/projects/*o/include/*.h]
>> (Ugh, I don't like the prefix '*' which I think you're using to mean
>> 'wildcards enabled'.)
>> I don't care what prefix we use, but I do care that the rules that contain
>> wildcards have a different syntax than the rules that do not. Otherwise,
>> existing authz files (that may contain literal wildcard/pattern characters)
>> would stop working.
>> We currently support two forms of patterns:
>> [/literal-fspath]
>> [repos:/literal-fspath]
>> the distinguishing feature is that in both cases, the literal-fspath must
>> begin with a slash, otherwise the rule is invalid. If we want to support
>> wildcards, we have to invent a different syntax for wildcard rules. My
>> working proposal is to add a literal '*' before the leading slash in the
>> path:
>> [*/fspath-pattern]
>> [repos:*/fspath-pattern]
>> because neither of these syntaxes are currently valid. We can invent a
>> different syntax, as long as it maintains that property; and we cannot
>> replace the brackets around the rule with something else, without making
>> very intrusive changes in the config parser code.
> Another approach might be to add an "options" section to the authz
> file (in a way that it is ignored by older servers), where one could
> specify a matching strategy (and if needed 'priority' strategy and so
> on).
> [options]
> matching = literal | basic-wildcards | regex | ...
> Then it's not hidden as a syntax-artifact, but more explicit ...

Yes, well, I really don't want to go overboard with options here. The
point of the exercise is to make current authz parsing a lot faster. If
we can get in some basic wildcard support that doesn't affect users who
do not use it, then fine; but confusing people with several different
pattern syntaxes is too much.

-- Brane

Branko Čibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
e. brane_at_wandisco.com
Received on 2014-07-29 13:06:13 CEST

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.