On Wed, 26 Mar 2008 10:15:05 -0400
"Akins, Brian" <[EMAIL PROTECTED]> 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/
