On Thursday 01 October 2015 13:55:40, Rainer Jung wrote:
> Am 01.10.2015 um 12:31 schrieb Graham Leggett:
> > On 01 Oct 2015, at 12:26 PM, Rainer Jung <[email protected]>
wrote:
> >> Since it gets more common to use the expression parser for string
> >> operations and not only for boolean checks, I think it would be
> >> useful (and powerful) to support
> >>
> >> s/PATTERN/REPLACEMENT/FLAGS
> >>
> >> and allow back references in REPLACEMENT. The operation would not
> >> try to do the replacement in place but create a new string
> >> according to the given PATTERN and REPLACEMENT.
> >>
> >> I had a quick look at the flex and bison files which generate
> >> lexer and parser but must admit that it wasn't immediately
> >> obvious to me how to do it. I can try harder but first wanted to
> >> ask if there are any volunteers who know that technology better
> >> than me. Stefan (Frisch)? Others?
I don't have much time for hacking httpd. But I will take a look.
> >> Otherwise I'll try myself (and learn new stuff on the way).
> >
> > We currently support a variation of this like this:
> > <LocationMatch /path/(?<PATHNAME>[^/]+)>
> >
> > SomeDirective %{env:MATCH_PATHNAME}
> >
> > </LocationMatch>
> >
> > Not sure if that’s what you had in mind, or if you’re trying to
> > achieve something different?
> Something different. Example:
>
> Header set X-USER "expr=%{REMOTE_USER} =~ s/([^@]*)@.*/$1/"
>
> So the string result of a s/PATTERN/REPLACEMENT/ should be the
> resulting REPLACEMENT string (if REMOTE_USER is "name@domain", the
> header value would be "name").
This is a bit complicated because you would probably not want this to
be a general part of the syntax of a string but rather a special case
in the "whole expression returns string" mode. Currently there is not
much infrastructure for behaving differently in both cases.
It may be a bit easier to implement if there was something at the
beginning of the expression to let the lexer recognize that this is
not your normal string expression and that the " =~ " is a special
token and not a normal substring.
Maybe like "expr=%! %{REMOTE_USER} =~ s/([^@]*)@.*/$1/"
But it must not be too complicated. We don't want an unreadable mess
like the sh/bash string manipulation functions.
Cheers,
Stefan
