httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
Date Thu, 01 Oct 2015 13:03:50 GMT
Doesn't mod_lua do this for you?

> On Oct 1, 2015, at 8:51 AM, Rainer Jung <> wrote:
> Am 01.10.2015 um 14:32 schrieb Nick Kew:
>> On Thu, 2015-10-01 at 12:26 +0200, Rainer Jung 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
>>> 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
>> Are you mixing two things?  That's well-established regexp syntax,
>> but you're looking at applying it to a different class expressions.
>> I think the most interesting issue is to define your behaviour.
>>> Header set X-USER "expr=%{REMOTE_USER} =~ s/([^@]*)@.*/$1/"
>> Aha!  In terms of the expression parser, that looks like
>> capturing a side-effect (as opposed to a true/false result).
>> Maybe it would work with something like C comma-list syntax?
>> But I expect the line of least resistance would be to use
>> plain regexp rather than expr.
> I'm talking about the use of the expression parser in the string context, not in boolean
context. Support for string context started some time back and we now support it in more and
more places. One could implement the
> syntax also as a four argument function regexreplace(var, PATTERN, REPLACEMENT, FLAGS),
but the notation using s/.../.../ should be well-known to many so IMHO is preferable.
> So I want to enhance the expr syntax in string context to allow
> This should return a string that is the result of the same operation in for example perl.
VARIABLE will not be changed - unlike in perl - but the result string will be s/PATTERN/REPLACEMENT/FLAGS
applied to VARIABLE.
> I think that is currently not possible with the expression parser but I expect it to
be useful and if noone has a recipe how to get it done with our flex/bison definitions I'll
try to find out.
> Since we don't support s/.../.../ right now, there shouldn't be to much compatibility
hassle with existing expressions.
> Regards,
> Rainer

View raw message