'No Input file specified' error - NginX / fcgi - when requesting non-existant .php file

Question

I have NginX serving a drupal site using fcgi. Attempting to browse to a non existent php file (eg. www.example.com/this-file-doesn't-exist.php) results in a white screen with this error:

'No Input file specified'

I used this post to help me set it up NginX: http://drupal.org/node/110224

This is my NginX config file:

server {
listen 1.2.3.4:80 default;
server_name www.example.com;

client_max_body_size 6M;

root /var/www/example.com/;
index index.php;

error_page 404 /index.php;
error_page 403 /403.html;

# set up a location to serve static images for static error pages
location ^~ /error_images/ {
  root   /var/www/static_pages/error_pages;
  access_log        off;
  expires           30d;
}

# use our own custom 403 page
location = /403.html {
  root   /var/www/static_pages/error_pages;
}

# redirect server error pages to the static page /50x.html
error_page 500 502 503 504  /50x.html;
location = /50x.html {
  root   /var/www/static_pages/error_pages;
}

location / {
  error_page 404 index.php;
  error_page 403 /403.html;

  # the main drupal app
  if (!-e $request_filename) {
    rewrite ^/(.*)$ /index.php?q=$1 last;
  }
}

# hide protected files
location ~* \.(engine|inc|info|install|module|profile|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)$|^(code-style\.pl|Entries.*|Repository|Root|Tag|Template)$ {
  deny all;
}

# serve static files directly
location ~* ^.+\.(jpg|jpeg|gif|css|png|js|ico)$ {
    rewrite ^/favicon.ico$ /sites/example.com/themes/exampletheme/favicon.ico break;
    access_log        off;
    expires           30d;
}

# imagecache needs to have php read any files that it's planning to manipulate
location ^~ /sites/example.com/files/imagecache/ {
   index  index.php index.html;
   # assume a clean URL is requested, and rewrite to index.php                                                                
    if (!-e $request_filename) {
        rewrite  ^/(.*)$  /index.php?q=$1  last;
        break;
    }
}

# serve the app via fastcgi
location ~ \.php$ {
    # ensure that a 404 is returned if a non existant php file is requested
    # doesn't seem to work properly, so commenting out
    # fastcgi_intercept_errors  on;
    fastcgi_pass unix:/tmp/php-fastcgi.sock;
    fastcgi_index index.php;
    fastcgi_read_timeout 240;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include /etc/nginx/fastcgi_params;
}

# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
location ~ /\.ht {
     deny  all;
}

}

This post http://forum.slicehost.com/comments.php?DiscussionID=1259 suggests that it may be a a permissions error. However, I start fcgi as the user:group nginx:nginx, which is the same user NginX runs as.

In general, the configuration works just fine, and the site works 100% as it should. It is only when requesting a .php file that doesn't exist that the problem occurs. Requesting a .html file that doesn't exist for example results in Drupal serving it's 404 error page - which is what I want to happen for non existent .php files too.

ps. if you want to view that that url, please remove the extra whitespace after http:// - I don't have enough rep to post more than one hyperlink!

Solution 1

You might to try using try_file instead.

See NGinx Best Practices

Eg for wordpress. Adapt accordingly.

location /wordpress {
    try_files $uri $uri/ @wordpress;
}

location @wordpress {
   fastcgi_pass 127.0.0.1:9000;
   fastcgi_split_path_info ^(/wordpress)(/.*)$;
   fastcgi_param SCRIPT_FILENAME /var/www/wordpress/index.php;
   fastcgi_param PATH_INFO $fastcgi_path_info;
}

Solution 2

The error is actually caused by PHP over fastcgi. You get the same response with apache. You can either cause your webserver to check that the file exists before sending it to php. With Apache you could do this using mod_rewrite, but I don't know enough about nginx to help you implement it. The alternative is to look to see if PHP has a config option that would allow you modify the behaviour when it can't find php file for the request.

Comments

[Adrian Heine]

I don't really see a difference to the configuration in the question.