Hi,
mod_include is still missing support for ap_expr. Trying to add that
support raises some questions:
The mod_include expression parser tries hard to limit what can be done.
For example, the subrequest operator -A can be switched of with a config
option. If mod_include was switched to ap_expr, this would open a lot of
possibilities in the expression parser, like reading arbitrary files with
the file() function, unrestricted file existance test, etc. I am not aware
how mod_include is actually used in production, but if the *shtml files
are untrusted, this could open a can of security problems. This is made
even worse by the fact that modules can extend ap_expr. So, what kind of
restrictions would be necessary for ap_expr in mod_include?
[ ] It would be enough to be able to switch back to the old, restricted
expression parser.
[ ] All functions / operators should be classified into safe for
mod_include or not safe for mod_include (with the classification being
hard-coded).
[ ] One would need a detailed way to configure which functions /
operators are allowed inside mod_include and which are not.
A different issue is that mod_include's parser is optimized for the
expressions being parsed and then evaluated only once. ap_expr on the
other hand is optimized for expressions being parsed once and then being
evaluated often. Therefore it is possible that ap_expr would be slower in
mod_include (but I haven't made any benchmark).
As I don't use mod_include, input from others would be very much
appreciated.
Cheers,
Stefan
