You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2017/10/31 14:01:18 UTC
[Bug 57448] SSI cannot capture backreferences from
regex match in
https://bz.apache.org/bugzilla/show_bug.cgi?id=57448
Richard Birkett <ri...@musicbox.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|2.4.7 |2.4-HEAD
CC| |richard-apache@musicbox.net
--- Comment #13 from Richard Birkett <ri...@musicbox.net> ---
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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org