Hi, the idea to have a generic expression parser and evaluator in httpd that can be used by various modules is certainly execellent. However, after spending some time on the current ap_expr parser, I am convinced that mod_include's old parser is not the right choice for this:
It is optimized for using a parsed expression only once: If using a parsed expression more than once, it copies the whole parse tree which makes it use a lot more memory when evaluating than e.g. the ssl_expr parser. Also, using recursion during expression evaluation would result in much more readable code than what ap_expr currently does. It does things during evaluation which should really be done during parsing: split strings into tokens for variable substitution, compile regexps, etc. The parsing of strings during evaluation creates a load of problems: - The syntax is very strange. E.g. one needs two backslashes to escape a $, the expression '$var'text is actually the same as '$var text' (i.e. a space is inserted), ... - If the result of an expression evaluation depends on the value of a request header, the HTTP response needs a corresponding Vary: header. This seems to be rather difficult to implement with the current approach. Since we won't be able to change the ap_expr syntax in any significant way after 2.4 has been released, we should try to do it right in 2.4. 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. Thoughts, comments? Cheers, Stefan
