httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: svn commit: r1032059 - /httpd/httpd/trunk/modules/filters/mod_include.c
Date Sun, 07 Nov 2010 14:16:32 GMT
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



View raw message