On Wed, Jun 21, 2017 at 2:00 PM, Jacob Champion <[email protected]> wrote:
> On 06/20/2017 02:19 PM, Jacob Champion wrote:
>>
>> Here's why I'm asking: if I were to propose the attached patch for
>> backport, what is the test case that *should* fail but doesn't?
>> (proxy_fcgi.t passes, no problem.) And once we get that test case, can we
>> show that it actually addresses a valid PHP-FPM use case, or is it a feature
>> without a user?
>
>
> Any thoughts on this?
I still cannot make any sense of what FPM is doing with our input.
I don't think either of the SCRIPT_NAME transformations make sense
just by the virtue of talking to FPM, primarily because it is neither
historically necessary or demonstrated as a problem.
if (fpm || apr_table_get(r->notes, "virtual_script")) {
/*
* Adjust SCRIPT_NAME, PATH_INFO and PATH_TRANSLATED for PHP-FPM
* TODO: Right now, PATH_INFO and PATH_TRANSLATED look OK...
*/
const char *pend;
const char *script_name = apr_table_get(r->subprocess_env,
"SCRIPT_NAME");
pend = script_name + strlen(script_name);
if (r->path_info && *r->path_info) {
pend = script_name + ap_find_path_info(script_name,
r->path_info) - 1;
}
while (pend != script_name && *pend != '/') {
pend--;
}
apr_table_setn(r->subprocess_env, "SCRIPT_NAME", pend);
ap_log_rerror(APLOG_MARK, APLOG_TRACE4, 0, r,
"fpm:virtual_script: Modified SCRIPT_NAME to: %s",
pend);
}
I would just as well pull this block out entirely rather than taking
the "fpm||" half of the test out. It seems like if you go out of your
way to run a script with PATH_INFO set as some parameter that we
shouldn't negate that. And like the non path_info case, nobody has
ever asked us for this.
