Yeah... that was something brought up earlier... leveraging ap_expr with access to things like r->path_info, etc directly. Right now, we don't have that mechanism, although we could likely leverage mod_lua maybe to hook in after subprocess_env has been populated and then adjust as needed.
> On Jan 26, 2017, at 7:56 AM, Eric Covener <cove...@gmail.com> wrote: > > On Thu, Jan 26, 2017 at 7:49 AM, Jim Jagielski <j...@jagunet.com> wrote: >> It seems that in many, many cases, we just to "adjust" a handful of >> the ennvars populated by ap_add_cgi_vars()... Right now, with my >> patch, we are doing it directly and explicitly in mod_proxy_fcgi. >> No doubt there are other places that need such special treatment >> as well. >> >> One possibility would be to continue in that fashion... Another >> would be to add some sort of hook/callback/fixup to ap_add_cgi_vars() >> that modules like mod_include, mod_proxy_fcgi,... can register. >> >> The latter seems "cleaner", for some reason, but most likely >> overkill for the limited cases we are dealing with. > > One thing Jacob brought up on iRC was the way nginx allows/encourages > you to set these things direclty by splitting/smashing variables > together. This might be good as a last resort so when people find > quirks they can at least resolve them without having every permutation > accounted for in the code. > > maybe we can peek at FCGI_FOO variables and overlay FOO after we call > the ap_add_cgi_vars? And people can use setenv/setenvif? > > Dunno if the evaluation is late enough though. You need to see the > output of the ap_add_* which to me implied you'd need an > expression-aware FCIG directive that is really evaluated right where > we'd do the override. > > -- > Eric Covener > cove...@gmail.com
