On Sat, 6 Nov 2010, Nick Kew wrote:
URL: http://svn.apache.org/viewvc?rev=1032059&view=rev
Log:
Put the expression parser back into mod_include
Hang on!
Surely we don't have to admit defeat in using a semi-universal expression
parser?
(I say semi, because mod_rewrite is probably too hard to convert).
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.
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
