On 06 Nov 2010, at 10:32 PM, Stefan Fritsch wrote:
I think I have made my intentions clear in my first mail from
October 23rd. But maybe I should have mentioned it also in the later
mails.
The grammar and in particular the string handling in the SSI
expression parser is so weird that it would be very difficult to
handle it in a backward compatible way with the same parser as the
ssl_expr grammar. At the minimum, one would need to rewrite the
tokenizer. Therefore I thought it a much more sensible approach to
handle the SSI expression compatibility by just putting that parser
back into mod_include. So the total number of parsers in httpd has
not changed by my work, but we now have the better parser as
univeral parser.
Of course it would be trivial to offer the new ap_expr as an
alternative in mod_include. Either by allowing to select the parser
with a config directive or by an alternative syntax in the SSI
document, like
'<!--#if apexpr="..."-->'. Does this sound reasonable? Which of the
two alternatives would you prefer? It may also be possible to at
least make the generalized variable lookup available in the old SSI
parser.
If we can offer a toggle switch directive, and declare the old syntax
as deprecated (and remove it in v2.6/v3.0), I think it would be ideal.
BTW, there are a number of other places where I want to allow
ap_expr as an alternative to the current syntax:
- SetEnvIf (maybe as SetEnvIf expr="..."?)
- Conditional access log (simply by using expr="..." instead of
env=...)
- maybe RewriteCond
+1.
Regards,
Graham
--
