William A. Rowe, Jr. wrote:
>SetEnvIf [really SetEnvIfMatch] and some other str[case]cmp SetEnvEqual
>could live in parallel, each optimized for a best case test.
>
Sounds good to me...how about these as the variants:
SetEnvIf (really SetEnvIfMatch): regex version
SetEnvEqual: full string match
SetEnvSubstring: substring match (faster alternative to regex for many
common user-agent matching rules)
SetEnvPrefix: prefix match
SetEnvSuffix: suffix match
The thinking behind those last two is that we could build a trie for
each and do really fast matching against an arbitrarily large number
of them. This would help in cases where somebody has a lot of file
extensions that need special handling, or a lot of prefix paths.
>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?
>
That makes sense, except for one part that I don't understand: what are the
input vars, if they're not the same as the request vars?
--Brian
