On Mon, Mar 03, 2014 at 04:11:52PM -0500, talkingnews wrote:

Hi there,

> I'd call myself very much a beginner with NGiNX, but I've been looking
> further through the documentation, particularly the
> http://wiki.nginx.org/Pitfalls page, and now I'm left with confusion!

The wiki is pretty much free for anyone to edit. The documentation is
somewhere else.

> 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).".
>
> But http://wiki.nginx.org/Pitfalls says:
> Set cgi.fix_pathinfo=0 in php.ini. This causes the PHP interpreter to only
> try the literal path given and to stop processing if the file is not found.

Two different wiki pages, two different authors with different
requirements and expectations. Probably.

The short version is: nginx and php and fastcgi are three different
things. nginx doesn't care what php configuration you use. nginx also
doesn't care if your php configuration works at all. It's the job of
the person doing the configuring to care about that.

> Which is correct?

You're more likely to get correct php advice on a php list.

I suspect that the only reason it is mentioned anywhere on the nginx
wiki is that some time ago, someone reported that they configured
their nginx to ask their fastcgi server to consider the filename
/var/www/file.txt/fake.php to be a php script; and the fastcgi server
and/or php interpreter instead processed the file /var/www/file.txt as
a php script; and that this was a problem and that it was also somehow
nginx's problem or fault.

(I agree it's a problem; I disagree it's nginx's problem.)

I'd say use "cgi.fix_pathinfo = 0", and fix any php script or environment
that has problems.

But I'd also say don't expect good knitting advice on a non-knitting list.

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

That's another php question. nginx doesn't care.

> In the server stanza there is:
>
> server {
> fastcgi_buffers 8 16k;
> fastcgi_buffer_size 32k;
> fastcgi_read_timeout 180;
> ....
>
> and then separately it says to add to fastcgi_params the following:
>
> fastcgi_connect_timeout 60;
> fastcgi_send_timeout 180;
> fastcgi_read_timeout 180;
> fastcgi_buffer_size 128k;
> fastcgi_buffers 4 256k;
> fastcgi_busy_buffers_size 256k;
> fastcgi_temp_file_write_size 256k;
> fastcgi_intercept_errors off;
>
> Some of those numbers are HUGE - most of the buffer defaults are normally
> 4k|8k. And 3 minutes between connections? Is this over-the-top? And the
> three items in server are conflicted by different values in fastcgi params.

Maybe those big values are suitable for that specific application. Or
maybe the random author who put it into the wiki found that this set of
values worked for them without testing what else might have worked.

In this case, putting values both at server level and in a file included
at location level means that the nginx inheritance rules will apply,
and not all of the server-level values will matter.

(And putting any non-fastcgi_param values in a file called fastcgi_params
is probably a poor idea.)

> And isn't that going to "pollute" the whole fpm server?

No.

Those settings are purely for the fastcgi client, which is nginx.

The only ones the server sees are fastcgi_param values -- and they are
random key/value pairs that nginx doesn't care about. The fastcgi server
does with them whatever it wants.

> I thought it would
> be better to have it in the fpm pool, so first I had it like this:
>
> php_value[upload_max_filesize] = 128M
> php_value[max_file_uploads] = 60
> php_value[default_socket_timeout] = 180
> php_value[date.timezone] = 'Europe/London'
> php_value[session.gc_maxlifetime] = 28800

php question.

> The I realised I only needed these high values for one area of my server, so
> again I changed it:
>
> location ~ /upload/ {
> location ~ \.(php)$ {
> try_files $uri =404;
> set $php_value "post_max_size = 128M";
> set $php_value "$php_value \n upload_max_filesize = 128M";
> set $php_value "$php_value \n session.gc_maxlifetime = 28800";
> set $php_value "$php_value \n max_file_uploads = 60";
> fastcgi_pass unix:/var/run/php5-fpm.sock;
> fastcgi_index index.php;
> fastcgi_param SCRIPT_FILENAME
> $document_root$fastcgi_script_name;
> fastcgi_param PHP_VALUE $php_value;
> include fastcgi_params;
> }
> }
>
> And it works fine. No core ini files are touched, only the area which need
> to change is changed.

Strictly a php question still. nginx (the fastcgi client) can send any
key/value pairs as fastcgi_params. What the fastcgi server does with them
is not nginx's concern. If your fastcgi server does something useful
with PHP_VALUE, then it can be useful for you to set it, like you do here.

But nginx doesn't know what the values mean, or what they invite your
fastcgi server to do.

> Also, the example config has:
>
> location ~ \.php {
> fastcgi_pass unix:/tmp/domain.sock;
> fastcgi_split_path_info ^(.+\.php)(.*)$;
> fastcgi_param SCRIPT_FILENAME
> $document_root$fastcgi_script_name;
> include fastcgi_params;
>
> But the Pitfalls guide suggests this is dangerous.

The Pitfalls guide should explain why it is suggests this is dangerous.

What url might match this location?

What fastcgi_param SCRIPT_FILENAME might your fastcgi server receive?

What file might your fastcgi server process as if it were a php script?

If you can't tell, then there's a danger -- but it's not necessarily on
the nginx side.

> So, my question would be:
>
> Is this example file wrong/outdated/dangerous?
>
> Or am I completely misunderstanding something?

I suspect that the multiple voices on the wiki have not explained clearly
to you why what they suggest is true, is true.

Perhaps it's not true at all. Or perhaps it is true in a specific set
of circumstances -- which differ for each voice.

Are things any clearer if you limit yourself to things at
http://www.nginx.org/ ? Perhaps there aren't enough examples there,
I don't know.

Good luck with it,

f
--
Francis Daly francis@daoine.org

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx