On 3/26/08 10:31 AM, "Nick Kew" <[EMAIL PROTECTED]> wrote:
> Straightforward: conditions on headers, method (obsoletes <Limit>),
> request line, env, CGI vars. With the option to disable conditional
> stuff for speed.
In mod_include, we parse into a tree on every request. For the
configuration, we should probably just parse it at startup and "run" it on
every request.
Also, currently, ap_expr is string specific, it would be nice if this was
provider based. Not sure of the exact interface, but it would be extendable
for other types of comparisons, for example.
typedef struct {
apr_status_t (*init_expr)(apr_pool_t *p, const char *lvalue, const char
*rvalue, int expr, void**data);
apr_status_t (*eval_expr)(reuqest_rec *r, void *data);
} ap_expr_provider_t;
So this expresssion, at startup:
<If Remote_IP =~ 10.189.>
...
</endif>
Would call the provider registered for "Remote_IP" as:
provider->init_expr(conf->pool, "Remote_IP", "10.189.", AP_EXPR_REGEX,
&data);
The provider would construct what ever struct it needs, in this case, to do
partial ip address matching, shove that into a struct and return it via the
data argument;
And then, at request time, we would run:
provider->eval_expr(r, data)
Where data is what was returned by init. This returns basically true or
false.
The string stuff could be easily integrated and provided "by default." The
nice thing, is all of this could be then used in mod_include as well, as
well as any other modules that use ap_expr.
Thoughts?
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
