On Wed, 26 Mar 2008 12:42:51 -0400
"Akins, Brian" <[EMAIL PROTECTED]> wrote:
> 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.
Indeed - hence the parse/eval separation in the proposed API.
> 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.
Well, we always start from a string. Later when it's tokenised
we can, and indeed do, dispatch to a provider (in mod_include's
case, functions called "handle_foo" for keyword foo).
> 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;
That's no use at top level, because
> So this expresssion, at startup:
>
> <If Remote_IP =~ 10.189.>
> ...
> </endif>
>
> Would call the provider registered for "Remote_IP" as:
we have to parse a string before we have Remote_IP.
Once we have that, sure, our evaluation function can dispatch
to the Remote_IP handler.
You seem to be looking a little further than my proposal went.
Which is kind-of why it would be good to hackathonise this:-)
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
