httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Champion <champio...@gmail.com>
Subject Re: Summary: Broken FastCGI with httpd
Date Thu, 19 Jan 2017 18:00:05 GMT
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 <champion.p@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)


Mime
View raw message