httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Zuelke>
Subject Re: Summary: Broken FastCGI with httpd
Date Thu, 19 Jan 2017 18:08:30 GMT
On 19.01.2017, at 19:00, Jacob Champion <> 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 <> 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.


>> Is [1] being used as the canonical place for this discussion w/ the
>> PHP Group?
>> 1.
> I'm not sure if there is a canonical place yet...
> is another possibility, if the conversation is picked up.

Yeah, not much interest yet, sorry :( Jim, I think you have a account; are you also
on that mailing list and can chime in?

> --Jacob
> [1],88845,88845#msg-88845
> [2]
>    (can't find a CVE right now, sorry)

View raw message