On Fri, Dec 5, 2014 at 9:23 PM, Jeff Trawick <traw...@gmail.com> wrote: > I guess PATH_INFO is the issue that affects the most people; thoughts? > > I guess expression-based support for overriding the default PATH_INFO > calculation is the basis for solving the widest variety of problems with any > of the variables, though I don't know if we'll have the right string > operations available (e.g., substring of dynamic length); thoughts?
I think this is still missing from string-returning expressions because you can't run a regex and return the backref. sf id say a long time ago when I asked about this that a module could run a boolean expression to set the backrefs, then reuse some kind of ap_expr context and still have the backrefs available (I've never actually looked at this part) My use case back then was something like spitting out part of a variable as the value in Header set foo "expr=" You can call single-argument functions that returns a string, and I believe that single argument is interpolated by ap_expr so it could be powerful. A function could then have its own delimeter to work around the problem with args. This is only worth discussing to save the work/risk in changing the expression parser itself. The function would not need to be fcgi specific, it would just be like e.g. PHP's preg_replace() or somehow in an operator (that isn't =~) -- Eric Covener cove...@gmail.com
