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.
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.
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.
--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)
