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