On Monday 25 October 2010, Nick Kew wrote:
> On 23 Oct 2010, at 12:36, Stefan Fritsch wrote:
> > Therefore I suggest to replace it with something that is closer
> > to ssl_expr. Initially, I thought it would be nice to have a SSI
> > compatibility mode, but now I think it would be cleaner to just
> > stick the SSI expression parser back into mod_include and not
> > deal with it further. On the other hand, maybe it is possible to
> > make ap_expr syntax compatible with ssl_expr and replace it. If
> > not, at least the evaluation logic should be shared between
> > ap_expr and ssl_expr.
>
> Would you expect to break API compatibility here? The current API
> is designed to admit some per-module variations (with expr_eval
> being passed string_func and eval_func as arguments), but also
> to make that, by default, unnecessary.
Yes, I intend to break API compatibility. The reason is that I want
variable interpolation to be part of the expression grammar and not
something that is done separately. I want the lookup of the
variables/functions/operators to happen during parsing, which should
be faster and gives the user an error message on startup if there is a
typo.
To allow per-module variations, I would allow the list of variables,
functions, and operators (things like "-a", i.e. what eval_func does
now) to be specified by the consumer. There would be a default list
for each of these three token types, with the possibility for modules
to register additional tokens. For example, mod_rewrite could register
its rewrite maps as functions, which would certainly allow interesting
applications.
The ap_expr consumers we have so far are:
mod_include
mod_filter
mod_headers
mod_authz_core
<If>
mod_include really needs the approach that variables are interpolated
as string function after the normal evaluation, and mod_include needs
to be fully backward compatible. All the other consumers are not in
2.2 or have a significantly different syntax anyway (mod_filter).
Therefore it seems the best approach to leave the old parser as legacy
in mod_include and take a fresh start with the other consumers.
Hopefully it is be possible to make the syntax a superset of ssl_expr
(or have a ssl-compat mode), so that we can replace ssl_expr in the
process.
My current ideas for the grammar are basically ssl_expr's syntax with
the following enhancements:
- have separate integer and string comparison operators (probably
shell-like: -gt, -eq, ... for ints, and >, =, <, ... for strings)
- allow variable interpolation in strings, keeping the %{...} syntax
for normal variables, and probably use $1, ... $9 for regexp back
references
- allow nested function calls
- allow concatenation of strings
- have unary operators like -e, -f, ... (like in shell)
Except for the integer and string comparison operators, all the
changes would be compatible with ssl_expr. ssl_expr currently has both
"gt", "lt", and "<", ">" which all do numerical comparison if the
operands are positive integers without leading zeros, and which do
something undefined otherwise.
