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 [email protected] _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
