httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: Dynamic configuration for the hackathon?
Date Wed, 26 Mar 2008 14:31:53 GMT
On Wed, 26 Mar 2008 10:15:05 -0400
"Akins, Brian" <Brian.Akins@turner.com> wrote:

> As to your suggestion:
> 
> So basically, the per_dir merge would use this mechanism instead of
> what it does now (file walk, location walk)> (or in addition to??)
> 
> Something like:
> 
> <If Directory == /www/stuff and Remote_IP =~ 10.189.>
>     SetEnv coolstuff
> <Elsif HTTP_Host == www.domain.com or Local_Port == 8080>
>     Set something different
> <Elsif ENV{blah} =~ foo or Cookie{baz} == iamset>
>     foo bar
> <Else>
>    something completely different
> </endif>

Sort-of.  There's a question of ordering: merge-config happens
before some of the vars we'd like to make available are available,
so we'd have a bit more work to make Cookie{baz} work (as opposed
to parsing a CGI-style HTTP_COOKIE variable).  But that's basically
the kind of thing.

Oh, and there's no inherent reason it shouldn't apply per-host
config too.

> (Horrible, example I know).  If it were easy to extend the expresions
> (ie, I want to implement (Cache == yes/no) and stuff like ENV{key}
> were made to work, I'm all for it.

Straightforward: conditions on headers, method (obsoletes <Limit>),
request line, env, CGI vars.  With the option to disable conditional
stuff for speed.  Higher-level stuff like *evaluating* caching or
cookie headers ... maybe sometime, but one could argue that's the
point where <Perl> or <Lua> makes more sense.

> It *should* be fairly easy to test this out with the current system
> (ala Proxy blocks).

Hopefully, yes.

Oh, and since ap_expr is a prerequisite for this, it would be great
if folks could review at least the API part (ap_expr.h) of what
I posted earlier.

-- 
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/

Mime
View raw message