Problems with fastcgi php migration

Server NGINX
21

Igor S. wrote:

}

Unfortunately, I tried both formats and it tosses a 404 when I try and
go to one of the extensionless files.

I’m assuming this is the order:

location / {
…
}

location ~ .(shtml|php)$ {
…fastcgi_pass stuff…
}

location ^/(galleries|poll|news/ {
…fastcgi_pass stuff…
}

22

Igor S. wrote:

location ~ ^/(galleries|poll|news)/ {

It’s one of those days…that didn’t work either.

Second, what’s about galleries/etc root ?

I have the root set to the same root as the other locations. Most of the
extensionless php files are in the site’s root directory, while others
can be found in multiple subdirectories, e.g.

galleries is off the main like example.com/galleries while the file
photos is run from, as an example:
example.com/fest/tiff/2007/1/photos
example.com/academy/80/photos
example.com/globes/56/photos

Back in the time when I tried lighttpd they had a fastcgi.map-extensions
config so you said something like “/galleries” => “.php”, “/photos” =>
“.php”, etc.

23

Ian M. Evans wrote:

In IE7:
calling /galleries/ causes a 404
calling /galleries runs the script as expected

Oddly, IE7 is now exposing the php script, so I guess I’m shutting that
test server down till I hear back… :slight_smile:

24

Igor S. wrote:

location ~ ^/(galleries|poll|news)/ {

Just did some further testing…

In IE7:
calling /galleries/ causes a 404
calling /galleries runs the script as expected

In Firefox:
calling /galleries/ causes a 404
calling /galleries gives a “Open with…/Save to disk” octet stream
dialogue.

Interesting…

25

Igor,

Just had a thought…could some of the problems with the extensionless
files I mentioned last night have anything to do with nginx not knowing
what content-type to send them as? Could that explain the one issue I
noticed where the browsers tried to download the files?

I’m hoping we’re just one or two quick changes from getting the site to
work fully under nginx.

Thanks.

26

On Tue, Mar 11, 2008 at 04:35:52PM -0400, Ian M. Evans wrote:

Just had a thought…could some of the problems with the extensionless
files I mentioned last night have anything to do with nginx not knowing
what content-type to send them as? Could that explain the one issue I
noticed where the browsers tried to download the files?

nginx does set any content-type for proxied and fastcgi responses.
It should be set by backend.

27

Igor S. wrote:

nginx does set any content-type for proxied and fastcgi responses.
It should be set by backend.

Then maybe it’s not that.

Can you think of any other reason why browsers would be trying to
download the extensionless files as opposed to seeing them as web pages?
As I said last night, the setting you suggested for the extensionless
files produced these results:

location ~ ^/(galleries|poll|news)/ {

In IE7:
calling /galleries/ causes a 404
calling /galleries runs the script as expected

In Firefox:
calling /galleries/ causes a 404
calling /galleries gives a “Open with…/Save to disk” octet stream
dialogue.

There has to be one final tweak that we’re missing. We’ve been running
the extensionless PHP file method for almost a decade under Apache, so
we must be missing one last thing that’s preventing us from ditching the
Apache backend and going 100% nginx.

28

Igor S. wrote:

telnet <your_site> 8088 <-- the nginx/fastcgi test is running at 8088
GET /galleries HTTP/1.0

show ?

GET /galleries HTTP/1.0

Using the MS Telnet client I’m getting a 400 Bad Request.

29

Ian M. Evans wrote:

Igor S. wrote:

telnet <your_site> 8088 <-- the nginx/fastcgi test is running at 8088
GET /galleries HTTP/1.0

show ?

GET /galleries HTTP/1.0

Using the MS Telnet client I’m getting a 400 Bad Request.

Actually it appears I’m getting the bad request on 80 and 8088 as soon
as I try to connect…before the GET, even though the site’s up and
running.

30

On Tue, Mar 11, 2008 at 04:56:24PM -0400, Ian M. Evans wrote:

There has to be one final tweak that we’re missing. We’ve been running
the extensionless PHP file method for almost a decade under Apache, so
we must be missing one last thing that’s preventing us from ditching the
Apache backend and going 100% nginx.

What does

telnet <your_site> 80
GET /galleries HTTP/1.0

show ?

31

On Tue, Mar 11, 2008 at 04:56:24PM -0400, Ian M. Evans wrote:

location ~ ^/(galleries|poll|news)/ {

In IE7:
calling /galleries/ causes a 404
calling /galleries runs the script as expected

In Firefox:
calling /galleries/ causes a 404
calling /galleries gives a “Open with…/Save to disk” octet stream
dialogue.

You need to change:

  • location ~ ^/(galleries|poll|news)/ {
  • location ~ ^/(galleries|poll|news)(/|$) {

because otherwise nginx handles /galleries, etc. as local files.

Then probably you need to set PATH_INFO:

location ~ ^/(galleries|poll|news)(/|$) {
set $path_info “”;
if ($uri ~ ^/[^/]+(/.+)) {
set $path_info $1;
}

   fastcgi_pass ...
   fastcgi_param  PATH_INFO $path_info;
   ...

}

32

On Tue, Mar 11, 2008 at 05:41:24PM -0400, Ian M. Evans wrote:

Using the MS Telnet client I’m getting a 400 Bad Request.

Actually it appears I’m getting the bad request on 80 and 8088 as soon
as I try to connect…before the GET, even though the site’s up and running.

It’s probably because of MS Telnet: it may send some control commands
before your text.

33

Igor S. wrote:

       set  $path_info  $1;
   }

   fastcgi_pass ...
   fastcgi_param  PATH_INFO $path_info;
   ...

}

The results:

Firefox:
Calling /galleries pulls up page. Adding further info (e.g. /30/1/1)
pulls up photo page as expected.

Calling /galleries/ (with trailing slash) still pulls up a 404 error.

IE7:
/galleries creates same passing result as Firefox.
/galleries/, like Firefox calls up the 404 page.

So we’re much, much closer…only stumbling block is getting it to run
properly if a visitor adds a trailing slash. Is that just a matter of
forcing no trailing slash if there’s nothing else following it?

Thanks.

34

Fernando,

Thanks for your email. The fastcgi settings I have are basically the
same as yours and all extensioned files (.php,.shtml) are working fine.

I had a problem with extensionless files that Igor solved with a special
regex for the path_info.

My only outstanding issue is that if the extensionless file is called
WITH a trailing slash and WITHOUT further path content I get a 404.

So remembering that /galleries is a FILE and not a directory:

/galleries calls the content it should (a main listing of photo events
/galleries/123/456/1 calls up a photo
/galleries/ tosses a 404

35

Hi Ian,

I’ve just lost 4 hours trying to make phpmyadmin work. The problem was
not passing the correct fastcgi_param.

Here is my fastcgi.conf file, try including it to your conf file:

/etc/nginx/fastcgi.conf

fastcgi_param PATH_INFO $fastcgi_script_name;

GATEWAY_INTERFACE is required otherwise python bugs

fastcgi_param GATEWAY_INTERFACE CGI/1.1;

fastcgi_param SERVER_SOFTWARE nginx;

Required otherwise the .cgi content is served as plain text

fastcgi_param QUERY_STRING $query_string;

Required for dealing with POST requests

fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;

fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param SERVER_ADDR $server_addr;

SERVER_PORT and SERVER_NAME are required

fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;

PHP only, required if PHP was built with --enable-force-cgi-redirect

#fastcgi_param REDIRECT_STATUS 200;

Also make sure you have SCRIPT_FILENAME correctly set, but it should be
as you can see some stuff being rendered.

Best regards,

36

Igor S. wrote:

Then you try to remove cgi.fix-pathinfo and to use the following:

Okay, changed cgi.fix-pathinfo to cgi.fix-pathinfo=0 Restarted the
fastcgi server, made the nginx changes and restarted.

   fastcgi_pass ...
   fastcgi_param  SCRIPT_FILENAME  $document_root$script_name;
   fastcgi_param  PATH_INFO        $path_info;
   ...

}

That didn’t work.

Firefox:
/galleries gave the application/octet stream download
/galleries/ gave a 404
/galleries/30/1/1 gave a 404

IE7:
/galleries displayed the PHP file
/galleries/ gave a 404
/galleries/30/1/1 gave a 404

Also, this appeared in the error log:
for /galleries/30/1/1:

[error] 13547#0: *59343 open()
“/usr/local/apache/htdocs/galleries/30/1/1” failed (20: Not a directory)

for /galleries/
[error] 13578#0: *59589 “/usr/local/apache/htdocs/galleries/index.shtml”
is not found (20: Not a directory)

So it appears that we were a bit closer with the previous email where
cgi.fix-pathinfo was on and the only 404 was when there was a trailing
slash after the filename.

Thanks.

37

On Tue, Mar 11, 2008 at 06:17:50PM -0400, Ian M. Evans wrote:

  if ($uri ~ ^/[^/]+(/.+)) {

So we’re much, much closer…only stumbling block is getting it to run
properly if a visitor adds a trailing slash. Is that just a matter of
forcing no trailing slash if there’s nothing else following it?

Then you try to remove cgi.fix-pathinfo and to use the following:

location ~ ^/(galleries|poll|news)(/|$) {

   set  $script_name  $uri;
   set  $path_info    "";

   if ($uri ~ ^(/[^/]+)(/.*)) {
       set  $script_name  $uri;
       set  $path_info    $1;
   }

   fastcgi_pass ...
   fastcgi_param  SCRIPT_FILENAME  $document_root$script_name;
   fastcgi_param  PATH_INFO        $path_info;
   ...

}

Then you should get the following:

URL SCRIPT_FILENAME PATH_INFO

/galleries $document_root/galleries -
/galleries/ $document_root/galleries /
/galleries/30/1/1 $document_root/galleries /30/1/1

38

On Wed, Mar 12, 2008 at 05:17:51AM -0400, Ian M. Evans wrote:

  set  $path_info    "";

}
/galleries displayed the PHP file
[error] 13578#0: *59589 “/usr/local/apache/htdocs/galleries/index.shtml”
is not found (20: Not a directory)

So it appears that we were a bit closer with the previous email where
cgi.fix-pathinfo was on and the only 404 was when there was a trailing
slash after the filename.

Add a single fastcgi_pass inside if:

        set  $path_info    $1;

  •       fastcgi_pass   ...
  }
39

Still trying to work out why, in my last mail (after I fixed my
cut’n’paste error), the path_info wasn’t getting populated with the
stuff after the / but instead the script.

Began trying to finally understand how regex works. So a question:

In your location:

if ($uri ~ ^(/[^/]+)(/.*)) {
set $script_name $uri;
set $path_info $1;
}

If I’m understanding the tutorial I’m reading, don’t the $NUM variables
get populated by the parantheses? So wouldn’t the set $path_info come
from $2 since you have two sets of ()?

I thought that might explain the findings from my last email:

URL: /testgalleries
the URL gave a 404 error

URL: /testgalleries/
PATH_INFO:/testgalleries with no trailing slash. Should be /

URL: /testgalleries/30/1/1
PATH_INFO: /testgalleries Should be /30/1/1

However, changing it to $2 created 404’s in each test case.

So I’m not sure why $path_info isn’t getting the right info.

Many thanks.

40

On Wed, Mar 12, 2008 at 05:23:52PM -0400, Ian M. Evans wrote:

set $path_info $1;
}

If I’m understanding the tutorial I’m reading, don’t the $NUM variables
get populated by the parantheses? So wouldn’t the set $path_info come
from $2 since you have two sets of ()?

This is my mistype, it should be:

set $script_name $1;
set $path_info $2;