From: "Brian Pane" <[EMAIL PROTECTED]> Sent: Wednesday, January 09, 2002 11:32 PM
> It may be helpful to decouple the two issues: > > * Should we have the logger itself check the content-type, or make it > check a variable set by something else? > > On the first issue, I'm in agreement with you: decoupling the metadata > check from the logger is a good thing. Setting a variable is a more > general-purpose solution that may be useful to other modules in the future. The variable schema has proven very worthwhile, and extensible. Let's stay focused on that, first off. > * Assuming that we use the set-a-variable approach, should SetEnvIf be > extended to do this, or should some new directive handle it? > > On the second issue, I'm still -1 on extending SetEnvIf because of its > inherent performance problems. I'd be in favor of adding a newer, more > efficient function to the mod_setenvif family of directives, > though--something > like "ExtensionMatch" or "ContentTypeMatch" that did an O(1) or O(log(N)) > lookup to match against N configured values. SetEnvIf [really SetEnvIfMatch] and some other str[case]cmp SetEnvEqual could live in parallel, each optimized for a best case test. I'm really thinking that SetEnvIf can be broken down into; request vars input vars output vars And these could be tested on at the appropriate points [output vars don't get tested until the -end- of fixups, for example.] This would make the entire EnvIf schema faster, even if that request vars subset needs to be tested more than once. Input vars don't change, so they only need testing once after parsing, output vars aren't complete till the fat lady sings, so to speak. Suppose this could be divided as such? Bill
