httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch>
Subject Re: svn commit: r1032059 - /httpd/httpd/trunk/modules/filters/mod_include.c
Date Sat, 06 Nov 2010 20:32:42 GMT
On Sat, 6 Nov 2010, Nick Kew wrote:
>> URL:
>> 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

View raw message