Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
On 06 Oct 2015, at 12:17 AM, Stefan Fritsch wrote: >> How about a regex function? >> >> The single argument could be “s/PATTERN/REPLACEMENT/FLAGS”. > > I think this would be easy to implement. It would require the regex to > be parsed on every execution, though, which has the disadvantages that > it is slower and that one would get error messages only during first > execution and not during server startup. Also, it would possibly allow > the admin to configure expressions where the regex pattern can contain > untrusted data, which would turn a lot of libpcre problems from local > into remote vulnerabilities. What I had in mind was for the regex to be precompiled at startup along with everything else, but I see now that it would need a special syntax anyway to distinguish it from arbitrary string data. Regards, Graham —
Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
On Sunday 04 October 2015 12:51:13, Graham Leggett wrote:
> On 04 Oct 2015, at 12:46 PM, Rainer Jung
wrote:
> > Yes, I agree. When starting to think closer, I noticed that the
> > string mode currently only supports a syntax that is pretty
> > different from the boolean mode and is much more limited. In that
> > mode everything is a string except it is marked via %{XXX}, in
> > which case XXX is a variable name, except XXX is AAA:BBB in which
> > case it is AAA("BBB").
> >
> > So AFAIK we don't support functions with more than one argument in
> > string mode and my naive idea of using "STRING =~
> > s/PATTERN/REPLACEMENT/FLAGS" runs into the problem, that we
> > currently don't support operators like "=~" etc. in string mode.
This is correct.
> > So I wonder whether it would be useful to allow for a more general
> > mode which would depending on operators or functions handle the
> > argument and result as strings or booleans using auto conversion
> > between them where needed. Of course in that mode verbatim
> > strings would need proper quoting (unlike pure string mode in
> > which everything by default is a verbatim string). We could then
> > even support>
> >BOOLEXPR ? STRINGEXPR1 : STRINGEXPR 2
> >
> > For compatibility that generalized mode would probably need a mode
> > differentiator syntax for compatibility reasons in 2.4 but could
> > be the default mode in trunk. Something like your "%!" prefix.
This is definitely a possible approach. I am not 100% sure that we
would want that mode to become the default, though, because it would
always require double quoting for simple string expressions. Like
LogMessage "'Foo=%{HTTP_FOO}'"
Somehow I also think this approach would be quite a bit of work,
especially to deal with all corner cases and ambiguities introduced by
auto conversion.
Another possible approach would be to implement functions with
multiple arguments in string mode first and worry about an easier
syntax second. If I remember correctly, I once planned to have
%{FUNCTION:'arg1','arg2'} as syntax for this. But i did not get
around to implementing it.
Now that I think of it, maybe
%{FUNCTION: X/arg1/arg2/arg3 }
would be another good syntax for it, where X is an (optional?) letter
and the / separator could be chosen from a list of separators, just
like is already possible with the m/foo/i regex syntax. Or make it
%{FUNCTION/arg1/arg2/arg3}
If we add optional whitespace at the beginning and end, and give our
rexec function an alias of 's', we would get something like
%{ s/TEXT/PATTERN/REPLACEMENT/FLAGS } or
%{ s/PATTERN/REPLACEMENT/FLAGS/TEXT/ }
which is not perfect but maybe acceptable from a readability point of
view.
> How about a regex function?
>
> The single argument could be “s/PATTERN/REPLACEMENT/FLAGS”.
I think this would be easy to implement. It would require the regex to
be parsed on every execution, though, which has the disadvantages that
it is slower and that one would get error messages only during first
execution and not during server startup. Also, it would possibly allow
the admin to configure expressions where the regex pattern can contain
untrusted data, which would turn a lot of libpcre problems from local
into remote vulnerabilities.
If everything else fails or goes nowhere, we can do this. But I would
like to try implementing a better solution, first.
Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
On 04 Oct 2015, at 12:51 PM, Graham Leggett wrote:
> How about a regex function?
>
> The single argument could be “s/PATTERN/REPLACEMENT/FLAGS”.
Or more specifically:
%{regex:%{REMOTE_USER} =~ /([^@]*)@.*/$1/}
Or perhaps to avoid the issue of having to escape the =~ characters this:
%{regex:/([^@]*)@.*/$1/%{REMOTE_USER}}
Regards,
Graham
—
Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
On 04 Oct 2015, at 12:46 PM, Rainer Jung wrote:
>> But it must not be too complicated. We don't want an unreadable mess
>> like the sh/bash string manipulation functions.
+1.
> Yes, I agree. When starting to think closer, I noticed that the string mode
> currently only supports a syntax that is pretty different from the boolean
> mode and is much more limited. In that mode everything is a string except it
> is marked via %{XXX}, in which case XXX is a variable name, except XXX is
> AAA:BBB in which case it is AAA("BBB").
>
> So AFAIK we don't support functions with more than one argument in string
> mode and my naive idea of using "STRING =~ s/PATTERN/REPLACEMENT/FLAGS" runs
> into the problem, that we currently don't support operators like "=~" etc. in
> string mode.
>
> So I wonder whether it would be useful to allow for a more general mode which
> would depending on operators or functions handle the argument and result as
> strings or booleans using auto conversion between them where needed. Of
> course in that mode verbatim strings would need proper quoting (unlike pure
> string mode in which everything by default is a verbatim string). We could
> then even support
>
>BOOLEXPR ? STRINGEXPR1 : STRINGEXPR 2
>
> For compatibility that generalized mode would probably need a mode
> differentiator syntax for compatibility reasons in 2.4 but could be the
> default mode in trunk. Something like your "%!" prefix.
How about a regex function?
The single argument could be “s/PATTERN/REPLACEMENT/FLAGS”.
Regards,
Graham
—
Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
Am 04.10.2015 um 10:23 schrieb Stefan Fritsch:
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
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:
[^/]+)>
SomeDirective %{env:MATCH_PATHNAME}
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.
Yes, I agree. When starting to think closer, I noticed that the string
mode currently only supports a syntax that is pretty different from the
boolean mode and is much more limited. In that mode everything is a
string except it is marked via %{XXX}, in which case XXX is a variable
name, except XXX is AAA:BBB in which case it is AAA("BBB").
So AFAIK we don't support functions with more than one argument in
string mode and my naive idea of using "STRING =~
s/PATTERN/REPLACEMENT/FLAGS" runs into the problem, that we currently
don't support operators like "=~" etc. in string mode.
So I wonder whether it would be useful to allow for a more general mode
which would depending on operators or functions handle the argument and
result as strings or booleans using auto conversion between them where
needed. Of course in that mode verbatim strings would need proper
quoting (unlike pure string mode in which everything by default is a
verbatim string). We could then even support
BOOLEXPR ? STRINGEXPR1 : STRINGEXPR 2
For compatibility that generalized mode would probably need a mode
differentiator syntax for compatibility reasons in 2.4 but could be the
default mode in trunk. Something like your "%!" prefix.
Regards,
Rainer
Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
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
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:
> >[^/]+)>
> >
> > SomeDirective %{env:MATCH_PATHNAME}
> >
> >
> >
> > 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
Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
On Thu, Oct 1, 2015 at 2:44 PM, Rainer Jung wrote: > > OK, at least an encouragement for me to have a closer look. +1!
Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
On 01 Oct 2015, at 4:31 PM, Nick Kew wrote:
>> Header set X-USER "expr=%{REMOTE_USER} =~ s/([^@]*)@.*/$1/"
>
> One further thought there that might be easier to work,
> or a staging post on the way to your goal:
>
>
>X-USER = $_
> # (or whatever backref syntax you prefer).
>
The reason I went with the named backref syntax only was the confusion
generated by nesting or duplicating the sections.
I would avoid any auto-numbered variables that leak outside the scope of a
single string expression so as to avoid side effects when two parts of the
config generate the same variable.
Regards,
Graham
—
Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
On Thu, 1 Oct 2015 15:25:38 +0200
Rainer Jung wrote:
> Am 01.10.2015 um 15:03 schrieb Jim Jagielski:
> > Doesn't mod_lua do this for you?
>
> But would it be the right tool to use whenever you want to apply a
> s/.../.../?
Some might say so (as some might say mod_perl or mod_rewrite).
> Header set X-USER "expr=%{REMOTE_USER} =~ s/([^@]*)@.*/$1/"
One further thought there that might be easier to work,
or a staging post on the way to your goal:
X-USER = $_
# (or whatever backref syntax you prefer).
--
Nick Kew
Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
Am 01.10.2015 um 15:03 schrieb Jim Jagielski:
Doesn't mod_lua do this for you?
But would it be the right tool to use whenever you want to apply a
s/.../.../? I think the entry bar for mod_lua is higher than to get used
with s/.../.../ syntax in the expression parser - though the docs for
expr could be better (have that on my list), especially concerning the
different syntaxes in boolean and string mode.
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
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.
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
var =~ s/PATTERN/REPLACEMENT/FLAGS
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
VARIABLE =~ s/PATTERN/REPLACEMENT/FLAGS
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
Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
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
>>>
>>> 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.
>>
>> 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
>
> var =~ s/PATTERN/REPLACEMENT/FLAGS
>
> 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
>
> VARIABLE =~ s/PATTERN/REPLACEMENT/FLAGS
>
> 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
Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
On Thu, 2015-10-01 at 13:32 +0100, Nick Kew wrote:
> > Header set X-USER "expr=%{REMOTE_USER} =~ s/([^@]*)@.*/$1/"
> But I expect the line of least resistance would be to use
> plain regexp rather than expr.
Come to think of it, using regexp that looks a lot like:
${REMOTE_USER} =~ s/([^@]*)@.*/$1/;
%header{X-USER} = $_;
I haven't tested the mod_perl syntax, but since it's
bog-standard perl, it's sure to be straightforward.
--
Nick Kew
Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
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
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.
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
var =~ s/PATTERN/REPLACEMENT/FLAGS
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
VARIABLE =~ s/PATTERN/REPLACEMENT/FLAGS
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
Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
Am 01.10.2015 um 14:33 schrieb Eric Covener: On Thu, Oct 1, 2015 at 6:26 AM, 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 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? Otherwise I'll try myself (and learn new stuff on the way). I've tried and failed to hack the exact same thing in a few times. I agree it would be great to have. OK, at least an encouragement for me to have a closer look. Regards, Rainer
AW: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
> -Ursprüngliche Nachricht- > Von: Rainer Jung > Gesendet: Donnerstag, 1. Oktober 2015 13:56 > An: dev@httpd.apache.org > Betreff: Re: Expression Parser: search and replace with > s/PATTERN/REPLACEMENT/FLAGS > > > The example might be artificial and mod_header might support doing this > in another way, but IMHO it would be a nice general feature for the > expression parser which would work without cooperation from the > modules/directives that use the expression parser. > +1 Regards Rüdiger
Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
On Thu, Oct 1, 2015 at 6:26 AM, 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 > > 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? > > Otherwise I'll try myself (and learn new stuff on the way). I've tried and failed to hack the exact same thing in a few times. I agree it would be great to have.
Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
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
>
> 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.
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.
--
Nick Kew
Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
On Thu, Oct 01, 2015 at 01:55:40PM +0200, Rainer Jung wrote:
> Something different. Example:
>
> Header set X-USER "expr=%{REMOTE_USER} =~ s/([^@]*)@.*/$1/"
>
> ...
>
> The example might be artificial and mod_header might support doing
> this in another way, but IMHO it would be a nice general feature for
> the expression parser which would work without cooperation from the
> modules/directives that use the expression parser.
This would be really neat. We have a few recipes where we abuse
ModSecurity or mod_rewrite to achieve this. Having it available
within the expression parser would simplify things a lot
(and get rid of timing and hook precedence issues).
Ahoj,
Christian Folini
--
Christian Folini -
Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
Am 01.10.2015 um 12:31 schrieb Graham Leggett:
On 01 Oct 2015, at 12:26 PM, 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
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?
Otherwise I'll try myself (and learn new stuff on the way).
We currently support a variation of this like this:
[^/]+)>
SomeDirective %{env:MATCH_PATHNAME}
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").
The example might be artificial and mod_header might support doing this
in another way, but IMHO it would be a nice general feature for the
expression parser which would work without cooperation from the
modules/directives that use the expression parser.
Regards,
Rainer
Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
On 01 Oct 2015, at 12:26 PM, 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
>
> 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?
>
> Otherwise I'll try myself (and learn new stuff on the way).
We currently support a variation of this like this:
[^/]+)>
SomeDirective %{env:MATCH_PATHNAME}
Not sure if that’s what you had in mind, or if you’re trying to achieve
something different?
Regards,
Graham
—
Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS
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? Otherwise I'll try myself (and learn new stuff on the way). Regards, Rainer
