php and locations with regex (round 2)

[Maxim Dounin]

Hello!

On Tue, 23 Oct 2007, Alejandro Vartabedian wrote:

> is the problem so obvious (and i very distracted) that nobody answer?

It is.

1.

According to your config (the second one) - there is no chance for nginx 
to use .php location for documents located under /app1/, since regex 
locations always checked in order (and ^/app1/ comes first).

2.

There is no such thing as "internal filename". It is what your browser 
suggests to you.

Maxim Dounin




>
> Alejandro Vartabedian escribiЪЪ:
>> (trying to pay attention to the data i posting...)
>>
>> well, i think i found a behavior pattern with my problem about regexed
>> locations and php scripts.
>> i tried very simple tests to figure out the behavior i getting from the
>> server.
>> the case is this:
>> _ 2 subdirs, app1 and app2
>> _ 2 files in each subdir index.html (hello world) and index.php (phpinfo)
>> _ 2 different locations configs, with and without regex
>> _ 2 different indexes en each app subdir, app1->index.php and
>> app2->index.html
>>
>> config 1:
>>
>>     server {
>>         listen       80;
>>         server_name  www.beta; #somename  alias  another.alias;
>>
>> #        access_log  /var/log/nginx/beta.access.log;
>>
>>         location / {
>>             root   /home/website/beta.ws/webroot/;
>>             index  index.php index.html index.htm;
>>         }
>>
>>         location /app1/ {
>>             root   /home/website/beta.ws/webroot/;
>>             index  index.php index.html index.htm;
>>         }
>>
>>         location /app2/ {
>>             root   /home/website/beta.ws/webroot/;
>>             index  index.html index.htm;
>>         }
>>
>>         # pass the PHP scripts to FastCGI server listening on 127.0.0.1:8888
>>         #
>>         location ~ .php$ {
>>             fastcgi_pass   127.0.0.1:8888;
>>             fastcgi_index  index.php;
>>             fastcgi_param  SCRIPT_FILENAME
>> /home/website/beta.ws/webroot$fastcgi_script_name;
>>             include        /etc/nginx/fastcgi_params;
>>         }
>>
>>     }
>> the behavior is as expected:
>>
>> http://www.beta/app1/ => index.php's phpinfo output
>> http://www.beta/app2/ => index.html's html hello world output
>>
>> http://www.beta/app1/index.php => index.php's phpinfo output
>> http://www.beta/app2/index.php => index.php's phpinfo output
>>
>> until now all is ok.
>>
>> now the config with a _minimal_ regex variation:
>>     server {
>>         listen       80;
>>         server_name  www.beta; #somename  alias  another.alias;
>>
>> #        access_log  /var/log/nginx/beta.access.log;
>>
>>         location / {
>>             root   /home/website/beta.ws/webroot/;
>>             index  index.php index.html index.htm;
>>         }
>>
>>         location ~ ^/(app1)/ {
>>             root   /home/website/beta.ws/webroot/;
>>             index  index.php index.html index.htm;
>>         }
>>
>>         location ~ ^/(app2)/ {
>>             root   /home/website/beta.ws/webroot/;
>>             index  index.html index.htm;
>>         }
>>
>>         # pass the PHP scripts to FastCGI server listening on 127.0.0.1:8888
>>         #
>>         location ~ .php$ {
>>             fastcgi_pass   127.0.0.1:8888;
>>             fastcgi_index  index.php;
>>             fastcgi_param  SCRIPT_FILENAME
>> /home/website/beta.ws/webroot$fastcgi_script_name;
>>             include        /etc/nginx/fastcgi_params;
>>         }
>>
>>     }
>>
>> the behavior isn't as expected:
>>
>> http://www.beta/app1/ => BIN file to download, 13ax1epp.bin containing
>> the index.php source code
>> http://www.beta/app2/ => index.html's html hello world output
>>
>> http://www.beta/app1/index.php => index.php's source code with a correct
>> mime recognition
>> http://www.beta/app2/index.php => index.php's source code with a correct
>> mime recognition
>>
>> well, it seems that as an automatic index the php file is returned with
>> some internal file name? with a .bin extension for download, containing
>> the script source code.
>> but if it's called directly by the browser url it's returned with the
>> correct name but without been parsed by the fastcgi.
>>
>> i hope it could be of help.
>>
>
>
>
>