Roy T. Fielding wrote: > On Aug 23, 2007, at 7:21 PM, William A. Rowe, Jr. wrote: >> Joshua Slive wrote: >>> On 8/23/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: >>> >>>> I'm happy with a number of alternative names, mod_pcre_filter, >>>> mod_text_filter, >>>> mod_subst_filter, whatever, a number come to mind. The fact is, >>>> mod_sed_filter >>>> was nothing close to a sed implementation. >>> >>> I hate "mod_rewrite_filter". That's just asking for confusion with >>> mod_rewrite. I prefer any of the above suggestions. (But then again, >>> I'm not planning to make the change myself, so feel free to ignore me.) > > That was my thought as well -- it is hard enough to document > mod_rewrite already. > >> I changed it, I'll be happy (urp) to change it again >> >> [ ] mod_pcre_filter >> [ ] mod_text_filter >> [*] mod_subst_filter >> [ ] mod_rewrite_filter > or [*] mod_substitute > or [*] mod_regex_replace, or ...
Yup, more good suggestions. (Transliterating your choices, and others sure can consider those too.) >> ...I believe we should extend the module to also accept env replacements >> from the current request. Sure, it's not there yet, but with that >> feature, it maps to rewrite more closely than most anything. > > And that's a good thing? Modules are supposed to be, well, modular. Of course :) Actually, the implementation looks nothing like mod_rewrite's. Given that the pattern match/replace is the most expensive, and the list of these substitutions is short, it's probably cheapest to build two pattern lists, those with env substitutions and those without. Those that have any substitions can build a temp table of those entries, appending on a copy of the constant list at request run time. (Of course the constants themselves would not be duplicated, just their indexes, and only if there are any dynamic entries to process). Bill
