(Just re-posting with a decent subject line so other people can see it.) - Julian
Johan Corveleyn wrote: > Branko Čibej wrote: >> On 29.07.2014 12:25, Julian Foad wrote: >>> Brane wrote: >>>> [*/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 ...
