On 19.01.2017, at 19:00, Jacob Champion <champio...@gmail.com> wrote: > > On 01/18/2017 01:00 PM, Jim Jagielski wrote: >> After all, it's easier for the FCGI server to know the SCRIPT_NAME >> than httpd to "guess"... > > I think the recent breakage calls this assumption into question. The server > admin knows exactly where the scripts are in the use cases we're currently > discussing; why should the backend have to "know" anything in those > situations? > > It's worth noting that letting PHP try to split apart SCRIPT_FILENAME on its > own has led to security issues in the past [1,2]. They were mitigated by > other means on the PHP side, I believe, but we can avoid recurrences in > future FCGI implementations. > >>> On Jan 18, 2017, at 2:01 PM, Jacob Champion <champio...@gmail.com> wrote: >>> We only get QUERY_STRING right. (Well, I won't say SCRIPT_FILENAME is >>> "wrong", since there is no standard definition, but it's not helpful.) >>> SCRIPT_NAME is supposed to point to a possible script-path (see RFC 3875 >>> for definitions), '/hello.php' in this instance. PATH_INFO and >>> PATH_TRANSLATED should not include 'hello.php' in their values. >> >> That is because we have no idea what SCRIPT_NAME is... > > One way to approach unknowns is to have httpd and/or the backend guess at > things; another way (that we can't start doing until a version-bump release) > is to refuse to send back a FastCGI request unless we know exactly what these > variables should be. That lets the user fix the issue and gain a better > understanding of what is going on, instead of relying on us and the backend > to perform magic together during the correct phase of the moon. > >> With the "guess" that >> it is /php7-fpm, then PATH_INFO kind of makes sense, since it is >> the portion of the URI following the script. And considering >> that we use >> >> Action application/x-php7-fpm /php7-fpm virtual >> >> the 2nd parameter is specifically noted as *being the cgi-script* and >> so of course httpd assumes that /php7-fpm is SCRIPT_NAME, because >> we explicitly called it that :) > > Fine by me. So then, in my opinion, it seems like one part of moving forward > should be to deprecate the use of Action to invoke script multiplexers like > PHP-FPM, and document accordingly. I.e. if you're not redirecting to *the > script*, as in standard CGI, no Action for you. > > (That explicitly deprecates the mod_fastcgi model for use with PHP-FPM, which > would also be fine by me. I don't like the way it couples the public > URI-space to an implementation detail.) > > Are there similar arguments for the variable values discussed in PR 51517? It > used ProxyPassMatch, not Action, for its implementation.
ProxyPassMatch has its own set of problems in combination with rewrites in e.g. .htaccess. The only method that I've found works reliably with any .htaccess rule that also works with e.g. mod_php is through SetHandler in 2.4.10+. >> Would it make sense, mostly from a PHP point-of-view, to send >> something like SCRIPT_FILENAME_RAW (or even >> APACHE_SCRIPT_FILENAME)... Or does that simply complicate an already >> fuzzy and nebulous situation? > > I think it probably makes things worse. It's just one more non-standard > variable for us to maintain and backends to manipulate. Agreed >> Is [1] being used as the canonical place for this discussion w/ the >> PHP Group? >> >> 1. https://github.com/php/php-src/pull/694#issuecomment-271963956 > > I'm not sure if there is a canonical place yet... > > http://news.php.net/php.internals/97810 > > is another possibility, if the conversation is picked up. Yeah, not much interest yet, sorry :( Jim, I think you have a php.net account; are you also on that mailing list and can chime in? > --Jacob > > [1] https://forum.nginx.org/read.php?2,88845,88845#msg-88845 > [2] https://bugs.php.net/bug.php?id=55181 > (can't find a CVE right now, sorry) >
