Re: [Pound Mailing List] Defining multiple URL patterns in a Service

On 3 May 2013 15:39, Joe Gooch <[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]]
> > Sent: Friday, May 03, 2013 8:13 AM
> > To: [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]> 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
> >
> >
> > --
> > To unsubscribe send an email with subject unsubscribe to
> > [email protected]
> > Please contact [email protected] for questions.
>