https://bz.apache.org/bugzilla/show_bug.cgi?id=57448
Richard Birkett <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|2.4.7 |2.4-HEAD CC| |[email protected] --- Comment #13 from Richard Birkett <[email protected]> --- I finally got round to migrating my SSI expressions to the "new" ap_expr syntax, and hit this bug. And it is clearly a bug. Because $0 is sometimes (though not always) exported from the "if" to a subsequent "set", you can hack it with extra matchers. Congratulations to the folks who discovered that, as it's a viable workaround! But it's clearly a hack, and doesn't work if you want to capture more than one substring. The documentation for ap_expr suggests that modules can, if they want to, allow the backref variables to survive between expressions. It's *partially* happening with SSI (but only with $0, and only if there are capturing parentheses, which in themselves shouldn't affect whether $0 is set), so please can it be fixed to work properly? I've taken a look at util_expr_eval.c and mod_include.c, and my guess is it's somewhere in the code in parse_ap_expr that decides whether to (re)allocate a backref_t struct within the persistent include_ctx_t. Hopefully somebody more familiar with this area of code will spot it! -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
