My staging branch now includes a URLMatch directive, which accepts a value of “Or” or “And”.
Joe From: Conor McCarthy [mailto:[email protected]] Sent: Tuesday, May 07, 2013 8:51 AM To: [email protected] Subject: Re: [Pound Mailing List] Defining multiple URL patterns in a Service On 3 May 2013 15:39, Joe Gooch <[email protected]<mailto:[email protected]>> wrote: If it were me, I'd implement OrUrl directives and AndUrl directives and ensure they could only use one or the other in the config. I could see a use case where OrUrl's would be useful for programs that are generating the config... I agree if the config is being modified manually, a pipe syntax in the regex is easy enough to do, and probably more efficient. (fewer regex calls) However, a url like (A|B|C|D|E|F|G|H|I|J|K|L|M) where each letter is actually 15-20 characters sounds like a management nightmare to me. Even if OrUrl directives were automagically translated into "(pat1|pat2|pat3|pat4)" by pound and compiled as one regex, it would likely be an improvement. As far as AndUrl directives, do you have an example of a use case where that would be useful? I get that ors can be handled natively and ands are more difficult... But what pair (or more) of patterns might one use? I'm finding it hard to conceptualize a time when someone would want to do that. "OrURL" handles my requirement neatly, I can only think of one marginal use case for "AndURL" since "and" is implicit in a regexp: AndURL "^/myapplication" AndURL" \.asp$" Which is of course equivalent to "^/myapplication.*\.asp$", but for non-trivial expressions it's arguably easier to read, maintain or generate. On platforms where PCRE is not available, you might usefully use AndURL to partially kludge some features (lookarounds or non-greedy matching). Since the expressions are compiled at config read time, the typical overheads should be minimal, at least for ^$ anchored expressions. C. Joe > -----Original Message----- > From: Robert Segall [mailto:[email protected]<mailto:[email protected]>] > Sent: Friday, May 03, 2013 8:13 AM > To: [email protected]<mailto:[email protected]> > Subject: Re: [Pound Mailing List] Defining multiple URL patterns in a > Service > > On Fre, 2013-05-03 at 12:47 +0100, Conor McCarthy wrote: > > On 29 April 2013 15:57, Joe Gooch > > <[email protected]<mailto:[email protected]>> wrote: > > > > > The documentation says you can have multiple directives… It doesn’t > > > indicate whether they’re and-ed or or-ed together. (The fact that > > > it calls them conditions leads me to believe they’re restrictive) > I > > > also agree the code appears to be doing an And relation.**** > > > > > > ** ** > > > > > > Personally it’s never occurred to me to try to use multiple URL > directives. > > > **** > > > > > > ** ** > > > > > > I agree in your case Or is what you want. I’m having a hard time > > > thinking of a reason you might want to use Ands… Maybe some sort > of > > > exclusionary rule using negative lookaheads.. but with regular > > > expressions I would think you could do that on one line as > well.**** > > > > > > ** ** > > > > > > “Or” logic committed to stage_for_upstream/v2.7b > > > > > > > Excellent, thanks! > > > > The specific use case is sets of URLs which require different Backend > > (and possibly Session) settings, so it's simplest to have a config > like: > > > > ListenHTTP > > > > Address 10.1.2.3 > > .... > > > > ## special URLs > > Service > > URL "^/url1" > > URL "^/url2" > > URL .... > > > > Backend > > ... > > End > > End > > > > ## default > > Service > > ... > > End > > End > > > > After a while a single URL regex with multiple grouped alternatives > > becomes troublesome and error prone. > > > > Regards, > > Conor. > > There is a reason for it: it is easy to write an OR regular expression, > but AND expressions can be more difficult. > -- > Robert Segall > Apsis GmbH > Postfach, Uetikon am See, CH-8707 > Tel: +41-32-512 30 19<tel:%2B41-32-512%2030%2019> > > > -- > To unsubscribe send an email with subject unsubscribe to > [email protected]<mailto:[email protected]>. > Please contact [email protected]<mailto:[email protected]> for questions.
