> On Jun 28, 2017, at 6:46 AM, Eric Covener <[email protected]> wrote:
>
> On Wed, Jun 28, 2017 at 5:50 AM, Jim Jagielski <[email protected]> wrote:
>> Is there someplace a set of examples on This Is What PHP and PHP-FPM
>> Expect These Values To Be?
>>
>> Like a whole slew of:
>>
>> For request: /blag/futo/gtyj.php?qur=kjr
>> SCRIPT_NAME: Should be /gtyj.php
>> PATH_INFO Should be /blag/futo
>> PATH_TRANSLATED Should be /Home/Charlie/public_html/site/blag/futo/
>>
>> or whatever?
>>
>> I think until we have something like this, we will be constantly
>> playing fetch-me-a-rock
>
> The problem is that FPM has very ugly code to second-guess most of
> these values based on other values and its own configuration. I just
> can't follow it. But we know it worked for quite a long time.
>
> We had not been fixing FPM compatibility for a very long time. We got
> into trouble because we tried to clean up some of the variables that
> FPM was already using as markers to ID mod_proxy_fcgi and cleaning up
> itself.
>
> The first of the modern problems was an attempt to make the variables
> consumable by non-FPM fcgi servers. That's the intent of having the
> ProxyFCGIBackendType (or whatever) so we can leave FPM input alone but
> do a better job on variables where they can be more directly verified
> without some overly complex layer second-guessing them.
FWIW, I'm looking thru
https://mail.python.org/pipermail/web-sig/2007-January/002475.html
Anyway, at least now we have in the test framework the ability to
test fcgi and php-fpm, if available, so we can at least ensure no
regressions or, if we like, finally "fix" things so that Apache and PHP
have similar expectations :)
