On Mon, Mar 3, 2014 at 10:11 PM, talkingnews <nginx-forum@nginx.us> wrote:
> This page http://wiki.nginx.org/PHPFcgiExample says
> "This guide run fine on php.ini cgi.fix_pathinfo = 1 (the default). Some
> guide insist to change it to cgi.fix_pathinfo = 0 but doing that make
> PHP_SELF variable broken (not equal to DOCUMENT_URI).".
>
To know what cgi.fix_path_info does depending on its value, rely on core
php.ini documentation<http://php.net/manual/en/ini.core.php#ini.cgi.fix-pathinfo>
..
The default value of '1' fixes an erroneous behavior of earlier PHP
versions not using PHP_INFO information properly. THe '0' value seems to
exist for backward-compatibility as it provides a broken environment.
Thus, scripts relying on such a value are highly suspicious to my eyes.
Where does the 'sites-available' directory of nginx came from? I do not
have such one (using Debian official stable package, currently 1.4.5).
Besides, there is no such DOCUMENT_URI server variable in PHP (at least as
of 4.1.0 as the list of PHP server
variableshttp://php.net/manual/en/reserved.variables.server.phpstates
and I wonder if it had ever existed before).
Another note: what the wiki says is not exact, refer to PHP documentation
to know the real impact of PHP configuration directives (sounds obvious...)..
The nginx wiki has not the reputation of being a trustable source of
information. Prefer referring to the official documentation, either nginx
or PHP one.
My second question: As I understand it, you should always make parameter
> changes only where they are needed, and in an overriding way - ie: one
> never
> touches php.ini itself.
>
Well, changing php.ini file modifies the behavior for all scripts using
it. If you have multiple environments needing different specific settings,
then it is indeed safer to configure them on-the-fly through FastCGI
parameterization of nginx. Thus, basing all your different configurations
on top of the default one is a rather straightward way of doing it.
Moreover, when updating PHP packages between major versions, its default
configuration files
usually also change. When you will wish to test your production setup for
an upgrade, you will be happier if you are as close to the original files
as possible.
But the Pitfalls guide suggests this is dangerous.
>
What exactly are you referring to in the pitfalls page saying that you
setup is dangerous?
---
*B. R.*
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
