Problem with fastcgi_split_path_info on ubuntu precise

Hi,

I must be missing something obvious here.
I rerun my ubuntu configuration script and suddenly my nginx setup not
working correctly anymore.

Here my relevant nginx config:

    location ~ [^/]\.php(/|$) {
            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            fastcgi_param PATH_INFO $fastcgi_path_info;
            try_files $fastcgi_script_name =404;

            fastcgi_pass unix:/var/run/php5-fpm.sock;
            fastcgi_index index.php;
            include fastcgi_params;
    }

And I test it with /test.php

<?php var_export($_SERVER)?>

When I request http://lemp.test/test.php/foo/bar.php the result is:

array (
‘USER’ => ‘www-data’,
‘HOME’ => ‘/var/www’,
‘FCGI_ROLE’ => ‘RESPONDER’,
‘PATH_INFO’ => ‘’,
‘QUERY_STRING’ => ‘’,
‘REQUEST_METHOD’ => ‘GET’,
‘CONTENT_TYPE’ => ‘’,
‘CONTENT_LENGTH’ => ‘’,
‘SCRIPT_FILENAME’ => ‘/var/www/test.php’,
‘SCRIPT_NAME’ => ‘/test.php’,
‘REQUEST_URI’ => ‘/test.php/foo/bar.php’,
‘DOCUMENT_URI’ => ‘/test.php’,
‘DOCUMENT_ROOT’ => ‘/var/www’,
‘SERVER_PROTOCOL’ => ‘HTTP/1.1’,
‘GATEWAY_INTERFACE’ => ‘CGI/1.1’,
‘SERVER_SOFTWARE’ => ‘nginx/1.4.0’,
‘REMOTE_ADDR’ => ‘192.168.56.1’,
‘REMOTE_PORT’ => ‘59200’,
‘SERVER_ADDR’ => ‘192.168.56.3’,
‘SERVER_PORT’ => ‘80’,
‘SERVER_NAME’ => ‘’,
‘HTTPS’ => ‘’,
‘REDIRECT_STATUS’ => ‘200’,
‘HTTP_HOST’ => ‘lemp.test’,
‘HTTP_USER_AGENT’ => ‘Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:20.0)
Gecko/20100101 Firefox/20.0’,
‘HTTP_ACCEPT’ =>
‘text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8’,
‘HTTP_ACCEPT_LANGUAGE’ => ‘en-US,en;q=0.5’,
‘HTTP_ACCEPT_ENCODING’ => ‘gzip, deflate’,
‘HTTP_CONNECTION’ => ‘keep-alive’,
‘HTTP_CACHE_CONTROL’ => ‘max-age=0’,
‘PHP_SELF’ => ‘/test.php’,
‘REQUEST_TIME’ => 1367630910,
)

What did I miss?

Sincerely yours,

– Zakaria

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,238825,238825#msg-238825

Have you added

cgi.fix_pathinfo=0

into /etc/php5/fpm/php.ini and restarted php?

Steve

On Fri, 2013-05-03 at 21:44 -0400, zakaria wrote:

            fastcgi_param PATH_INFO $fastcgi_path_info;
<?php var_export($_SERVER)?>

‘REQUEST_METHOD’ => ‘GET’,
‘REMOTE_ADDR’ => ‘192.168.56.1’,
‘text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8’,

http://mailman.nginx.org/mailman/listinfo/nginx

Steve H. BSc(Hons) MIITP
http://www.greengecko.co.nz
Skype: sholdowa

On Fri, May 03, 2013 at 09:44:14PM -0400, zakaria wrote:

Hi there,

I must be missing something obvious here.
I rerun my ubuntu configuration script and suddenly my nginx setup not
working correctly anymore.

What output do you expect?

And if it not obvious: how does that differ from this output?

I think you’re reporting that PATH_INFO is unexpectedly empty
in $_SERVER, in which case adding “fastcgi_param TEST_PATH_INFO
$fastcgi_path_info;” and retrying might give a hint as to where the
problem is.

f

Francis D. [email protected]

Not much different, now even PHP_SELF not set!

array (
‘USER’ => ‘www-data’,
‘HOME’ => ‘/var/www’,
‘FCGI_ROLE’ => ‘RESPONDER’,
‘PATH_INFO’ => ‘’,
‘QUERY_STRING’ => ‘’,
‘REQUEST_METHOD’ => ‘GET’,
‘CONTENT_TYPE’ => ‘’,
‘CONTENT_LENGTH’ => ‘’,
‘SCRIPT_FILENAME’ => ‘/var/www/test.php’,
‘SCRIPT_NAME’ => ‘/test.php’,
‘REQUEST_URI’ => ‘/test.php/foo/bar.php’,
‘DOCUMENT_URI’ => ‘/test.php’,
‘DOCUMENT_ROOT’ => ‘/var/www’,
‘SERVER_PROTOCOL’ => ‘HTTP/1.1’,
‘GATEWAY_INTERFACE’ => ‘CGI/1.1’,
‘SERVER_SOFTWARE’ => ‘nginx/1.4.0’,
‘REMOTE_ADDR’ => ‘192.168.56.1’,
‘REMOTE_PORT’ => ‘55961’,
‘SERVER_ADDR’ => ‘192.168.56.3’,
‘SERVER_PORT’ => ‘80’,
‘SERVER_NAME’ => ‘’,
‘HTTPS’ => ‘’,
‘REDIRECT_STATUS’ => ‘200’,
‘HTTP_HOST’ => ‘lemp.test’,
‘HTTP_USER_AGENT’ => ‘Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:20.0)
Gecko/20100101 Firefox/20.0’,
‘HTTP_ACCEPT’ =>
‘text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8’,
‘HTTP_ACCEPT_LANGUAGE’ => ‘en-US,en;q=0.5’,
‘HTTP_ACCEPT_ENCODING’ => ‘gzip, deflate’,
‘HTTP_CONNECTION’ => ‘keep-alive’,
‘HTTP_CACHE_CONTROL’ => ‘max-age=0’,
‘PHP_SELF’ => ‘’,
‘REQUEST_TIME’ => 1367637739,
)

GreenGecko Wrote:

            fastcgi_param PATH_INFO $fastcgi_path_info;

‘HOME’ => ‘/var/www’,
‘DOCUMENT_ROOT’ => ‘/var/www’,
‘HTTP_HOST’ => ‘lemp.test’,
‘REQUEST_TIME’ => 1367630910,

Steve H. BSc(Hons) MIITP
http://www.greengecko.co.nz
Skype: sholdowa

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,238825,238827#msg-238827

It seems that PATH_INFO is sensitive to points being used in URI…
Check the PHP doc about
$_SERVERhttp://www.php.net/manual/en/reserved.variables.server.php:
a very interesting example is being provided there.

Ubuntu is much likely not the problem.
Since you are a ‘good sysadmin’, you also tried to relate trouble to
some
recent update of packages if any. :o)
If nothing changed in your setup or in your configuration, then it comes
from bad/unreliable usage of unknown resources.

Hope that I helped,

B. R.

Francis D. Wrote:

On Fri, May 03, 2013 at 09:44:14PM -0400, zakaria wrote:

Hi there,

What output do you expect?

And if it not obvious: how does that differ from this output?

I think you’re reporting that PATH_INFO is unexpectedly empty
in $_SERVER, in which case adding “fastcgi_param TEST_PATH_INFO
$fastcgi_path_info;” and retrying might give a hint as to where the
problem is.

f

Francis D. [email protected], that’s what I mean.

I’m sorry for being cryptic but this problem has me puzzled for two
days.

Let me tell the long story.
I’m trying to setup a web server using nginx in ubuntu 12.04.2 (precise)
Like any good sysadmin, I use bash script to setup everything.
So I could replay it anytime.

So on the friday I rerun the script (to enhanced it) and it didn’t work
like
it used to.
I swear, I got nginx working perfectly before with PATH_INFO and all.

To answer your question. The PATH_INFO should output to ‘/foo/bar.php’

Per your request here’s my modified config

    location ~ [^/]\.php(/|$) {
            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            fastcgi_param PATH_INFO $fastcgi_path_info;
            fastcgi_param TEST_PATH_INFO    $fastcgi_path_info;
            try_files $fastcgi_script_name =404;

            fastcgi_pass unix:/var/run/php5-fpm.sock;
            fastcgi_index index.php;
            include fastcgi_params;
    }

And the result with cgi.fix_pathinfo = 1 (the default)

array (
‘USER’ => ‘www-data’,
‘HOME’ => ‘/var/www’,
‘FCGI_ROLE’ => ‘RESPONDER’,
‘PATH_INFO’ => ‘’,
‘TEST_PATH_INFO’ => ‘’,
‘QUERY_STRING’ => ‘’,
‘REQUEST_METHOD’ => ‘GET’,
‘CONTENT_TYPE’ => ‘’,
‘CONTENT_LENGTH’ => ‘’,
‘SCRIPT_FILENAME’ => ‘/var/www/test.php’,
‘SCRIPT_NAME’ => ‘/test.php’,
‘REQUEST_URI’ => ‘/test.php/foo/bar.php’,
‘DOCUMENT_URI’ => ‘/test.php’,
‘DOCUMENT_ROOT’ => ‘/var/www’,
‘SERVER_PROTOCOL’ => ‘HTTP/1.1’,
‘GATEWAY_INTERFACE’ => ‘CGI/1.1’,
‘SERVER_SOFTWARE’ => ‘nginx/1.4.0’,
‘REMOTE_ADDR’ => ‘192.168.56.1’,
‘REMOTE_PORT’ => ‘33683’,
‘SERVER_ADDR’ => ‘192.168.56.3’,
‘SERVER_PORT’ => ‘80’,
‘SERVER_NAME’ => ‘’,
‘HTTPS’ => ‘’,
‘REDIRECT_STATUS’ => ‘200’,
‘HTTP_HOST’ => ‘lemp.test’,
‘HTTP_USER_AGENT’ => ‘Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:20.0)
Gecko/20100101 Firefox/20.0’,
‘HTTP_ACCEPT’ =>
‘text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8’,
‘HTTP_ACCEPT_LANGUAGE’ => ‘en-US,en;q=0.5’,
‘HTTP_ACCEPT_ENCODING’ => ‘gzip, deflate’,
‘HTTP_CONNECTION’ => ‘keep-alive’,
‘HTTP_CACHE_CONTROL’ => ‘max-age=0’,
‘PHP_SELF’ => ‘/test.php’,
‘REQUEST_TIME’ => 1367710298,
)

So here’s my request to you all:

  1. Is my config correct? I’m sure it is.
  2. Could you try it on your system and
    tell me whether the output differ from mine?
  3. Is there something wrong on the latest ubuntu precise?
    Or is it just my imagination that I have it working before? :slight_smile:

Thanks,

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,238825,238849#msg-238849

On Sat, May 04, 2013 at 07:41:43PM -0400, zakaria wrote:

Francis D. Wrote:

Hi there,

So on the friday I rerun the script (to enhanced it) and it didn’t work like
it used to.
I swear, I got nginx working perfectly before with PATH_INFO and all.

To answer your question. The PATH_INFO should output to ‘/foo/bar.php’

And the result with cgi.fix_pathinfo = 1 (the default)

As an aside – I find that “cgi.fix_pathinfo = 1” removes the “do what
I say” part of php configuration, so I run without it. But I don’t
believe that that’s relevant here.

‘PATH_INFO’ => ‘’,
‘TEST_PATH_INFO’ => ‘’,

Thanks for testing that. It suggests to me that the problem is on the
nginx side: $fastcgi_path_info is empty at the time the fastcgi_param
directive takes effect.

So here’s my request to you all:

  1. Is my config correct? I’m sure it is.

It doesn’t do what you want it to do, which is a strong hint in one
direction :wink:

But I don’t see any reason why that should be the case.

I do see two possible config changes you could make, each of which seems
enough to get things working as you want.

Either: remove the “try_files” line; or replace the “fastcgi_param
PATH_INFO” line with two lines:

fastcgi_param PATH_INFO $mypath;
set $mypath $fastcgi_path_info;

These seem to work because $fastcgi_path_info does have the correct
value in the “rewrite” phase, but loses it after the “try files” phase.
I
don’t understand why that is the case. That upsets me.

  1. Could you try it on your system and
    tell me whether the output differ from mine?

I get the same output, using both nginx 1.2.4 and 1.0.0.

And either change “fixes” it on each.

  1. Is there something wrong on the latest ubuntu precise?
    Or is it just my imagination that I have it working before? :slight_smile:

Were you perhaps previously using an older nginx version where it worked
as expected?

Or is the “try_files” line a new addition since Friday?

f

Francis D. [email protected]

Francis D. Wrote:

Hi there,

And the result with cgi.fix_pathinfo = 1 (the default)

As an aside – I find that “cgi.fix_pathinfo = 1” removes the “do what
I say” part of php configuration, so I run without it. But I don’t
believe that that’s relevant here.

cgi.fix_pathinfo=0 gives incorrect PHP_SELF.

‘PATH_INFO’ => ‘’,
‘TEST_PATH_INFO’ => ‘’,

Thanks for testing that. It suggests to me that the problem is on the
nginx side: $fastcgi_path_info is empty at the time the fastcgi_param
directive takes effect.

So here’s my request to you all:

  1. Is my config correct? I’m sure it is.

It doesn’t do what you want it to do, which is a strong hint in one
direction :wink:

But I don’t see any reason why that should be the case.

I do see two possible config changes you could make, each of which
seems
enough to get things working as you want.

Either: remove the “try_files” line; or replace the “fastcgi_param
PATH_INFO” line with two lines:

fastcgi_param PATH_INFO $mypath;
set $mypath $fastcgi_path_info;

These seem to work because $fastcgi_path_info does have the correct
value in the “rewrite” phase, but loses it after the “try files”
phase. I don’t understand why that is the case. That upsets me.

Thank you for confirm it.
Its nginx bug #321 http://trac.nginx.org/nginx/ticket/321

For the benefit of the man from the future (http://xkcd.com/979/),
here’s my final configuration:

    location ~ [^/]\.php(/|$) {
            fastcgi_split_path_info ^(.+?\.php)(/.*)$;
            # Save the $fastcgi_path_info before try_files clear it
            set $path_info $fastcgi_path_info;
            fastcgi_param PATH_INFO $path_info;
            try_files $fastcgi_script_name =404;

            fastcgi_pass unix:/var/run/php5-fpm.sock;
            fastcgi_index index.php;
            include fastcgi_params;
    }

with /test.php:

<?php var_export($_SERVER) ?>

and php.ini cgi.fix_pathinfo = 1 (the default).

When given request http://lemp.test/test.php/foo/bar.php?v=1 would
produce:

array (
‘USER’ => ‘www-data’,
‘HOME’ => ‘/var/www’,
‘FCGI_ROLE’ => ‘RESPONDER’,
‘PATH_INFO’ => ‘/foo/bar.php’,
‘QUERY_STRING’ => ‘v=1’,
‘REQUEST_METHOD’ => ‘GET’,
‘CONTENT_TYPE’ => ‘’,
‘CONTENT_LENGTH’ => ‘’,
‘SCRIPT_FILENAME’ => ‘/var/www/test.php’,
‘SCRIPT_NAME’ => ‘/test.php’,
‘REQUEST_URI’ => ‘/test.php/foo/bar.php?v=1’,
‘DOCUMENT_URI’ => ‘/test.php’,
‘DOCUMENT_ROOT’ => ‘/var/www’,
‘SERVER_PROTOCOL’ => ‘HTTP/1.1’,
‘GATEWAY_INTERFACE’ => ‘CGI/1.1’,
‘SERVER_SOFTWARE’ => ‘nginx/1.1.19’,
‘REMOTE_ADDR’ => ‘192.168.56.1’,
‘REMOTE_PORT’ => ‘46281’,
‘SERVER_ADDR’ => ‘192.168.56.3’,
‘SERVER_PORT’ => ‘80’,
‘SERVER_NAME’ => ‘localhost’,
‘HTTPS’ => ‘’,
‘REDIRECT_STATUS’ => ‘200’,
‘HTTP_HOST’ => ‘lemp.test’,
‘HTTP_USER_AGENT’ => ‘Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:20.0)
Gecko/20100101 Firefox/20.0’,
‘HTTP_ACCEPT’ =>
‘text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8’,
‘HTTP_ACCEPT_LANGUAGE’ => ‘en-US,en;q=0.5’,
‘HTTP_ACCEPT_ENCODING’ => ‘gzip, deflate’,
‘HTTP_CONNECTION’ => ‘keep-alive’,
‘PHP_SELF’ => ‘/test.php/foo/bar.php’,
‘REQUEST_TIME’ => 1367750028,
)

  1. Is there something wrong on the latest ubuntu precise?
    Or is it just my imagination that I have it working before? :slight_smile:

Were you perhaps previously using an older nginx version where it
worked as expected?

Or is the “try_files” line a new addition since Friday?

Most probably, I forget to reload the server after I changed the config
(combining try_files with fastcgi_split_path_info),
try it in the browser thinking all is well.

Thank you all for helping this nginx newbie.

f

Francis D. [email protected]

– Zakaria

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,238825,238860#msg-238860

B.R. Wrote:

It seems that PATH_INFO is sensitive to points being used in URI…
Check the PHP doc about $_SERVER
http://www.php.net/manual/en/reserved.variables.server.php:
a very interesting example is being provided there.

Yes, I knew that.
If you read from the beginning of the thread,
the request is from /test.php/foo/bar.php
and I try it with another URI that should have PATH_INFO.

Ubuntu is much likely not the problem.
Since you are a ‘good sysadmin’, you also tried to relate trouble to some
recent update of packages if any. :o)

This is fresh install, so it kind a hard to see whats updated than
before.
But thanks for the idea.

If nothing changed in your setup or in your configuration, then it
comes from bad/unreliable usage of unknown resources.

I presume you find nothing wrong with my config?

Hope that I helped,

B. R.

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,238825,238851#msg-238851

Francis D. Wrote:

    location ~ [^/]\.php(/|$) {

probably be left alone.
http://mailman.nginx.org/mailman/listinfo/nginx
Francis, could you please show me an example?

I’m encountering this issue on Ubuntu 12.04.2 LTS while trying to set up
Phalcon; a c lib/framework for PHP. So far the other fixes in this
thread
haven’t worked.

Phalcon’s Doc: http://docs.phalconphp.com/en/latest/reference/nginx.html

I think Phalcon is dependent on how fastcgi_split_info works, so I’m
trying
to “replicate” how it handles the rewrite using regex. Am I going about
this the wrong way?

Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,238825,239155#msg-239155

On Sun, May 05, 2013 at 07:04:21AM -0400, zakaria wrote:

Francis D. Wrote:

Hi there,

Thank you for confirm it.
Its nginx bug #321 http://trac.nginx.org/nginx/ticket/321

Ah, good find – I hadn’t spotted that it was a “known issue”.

    location ~ [^/]\.php(/|$) {

Just as another alternative, it is probably possible to use named
captures
in the “location” regex and avoid using fastcgi_split_path_info at all

with everything up to and including “.php” being used as the script
name,
and something like “(/.*)?$” being the path info.

But what you have here already looks like it should be working, so can
probably be left alone.

Cheers,

f

Francis D. [email protected]

On Tue, May 14, 2013 at 10:17:13AM -0400, vilsack wrote:

Francis D. Wrote:

On Sun, May 05, 2013 at 07:04:21AM -0400, zakaria wrote:

Hi there,

    location ~ [^/]\.php(/|$) {

Just as another alternative, it is probably possible to use named captures
in the “location” regex and avoid using fastcgi_split_path_info at all
– with everything up to and including “.php” being used as the script
name, and something like “(/.*)?$” being the path info.

Francis, could you please show me an example?

location ~ ^(?<script_name>.+.php)(?<path_info>/.*)?$ {

is one possible way.

Then use $script_name and $path_info as you see fit.

I’m encountering this issue on Ubuntu 12.04.2 LTS while trying to set up
Phalcon; a c lib/framework for PHP. So far the other fixes in this thread
haven’t worked.

“this issue” is “everything works fine, until you use try_files in
the same location as fastcgi_split_path_info”, unless I misunderstand
things. It should be easy enough to test – just comment out the
try_files
and see that your request gives the expected response.

Phalcon’s Doc: http://docs.phalconphp.com/en/latest/reference/nginx.html

I think Phalcon is dependent on how fastcgi_split_info works, so I’m trying
to “replicate” how it handles the rewrite using regex. Am I going about
this the wrong way?

That Phalcon doc seems to suggest four distinct and different ways
of configuring nginx, so that it works with four different ways of
configuring Phalcon.

None of them seem to use try_files in the same (useful) location as
fastcgi_split_path_info.

What is the one way that you have configured Phalcon?

What is the matching one way that you have configured nginx?

What request do you make, what response do you get, and what response
do you expect?

If your testing suggests that this is a different issue, it’s probably
worth creating a new thread for further responses.

Cheers,

f

Francis D. [email protected]