httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Leggett" <>
Subject Re: Expression Parser API?
Date Wed, 28 Nov 2007 10:43:02 GMT
On Wed, November 28, 2007 2:31 am, Nick Kew wrote:

> I've extracted the expression parser from mod_include into an
> ap_expr.c file.  It was surprisingly straightforward, and loses
> none of the functionality of mod_include[1].
> The API now includes a string parser function, used where mod_include
> uses ap_ssi_parse_string.  I'm happy with that.  However, to avoid
> losing any mod_include functionality, we also have to pass accessenable
> as an argument, which is ugly.  I think it would be better to drop
> accessenable (and the consequent subrequest stuff) from the parser.

So if the solution doesn't fit the problem, just change the problem?

-1 to that.

Looking at parse_expr(), the -A section slots in the section headed
"evaluate parse tree", the section that performs the logic parsing of
conditional expressions.

The existing mod_include conditional code performs functions on "stuff we
already know", for example "string1 greater than string2". Both string1
and string2 are static and known in advance of parsing, and the comparison
is trivial.

The -A function in the conditional code falls into the category of "stuff
we don't already know". We cannot know the result of "-A /url" in advance
of running the parser, because we do not know until parse time as to the
value of "/url", nor is it practical for the module to generate an
infinitely long list of potential urls to which the user does have access.

In order for a generic parser to be even a little bit generic, I would
expect it to be possible to pass a pointer to a comparison function
capable of being triggered when a token -Something is encountered.

There is no reason why the generic parsing code needs any specific
knowledge of the -A code, nor is there any requirement to remove the -A
option to make this work.


View raw message