Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My current host uses FastCGI for its PHP setup, and this is apparently causing some issues when a mod_rewrite directive redirects to a URL with a PATH_INFO portion. For example, there are issues when using the following:

RewriteEngine on

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^(.*)$ index.php/$1

When using the above, navigating to a rewritten URL results in the 'No input file specified." error message from PHP, meaning that PHP wasn't appropriately passed a file to parse.

I've been able to learn from web searches that this issue only appears when PHP is being run under FastCGI, but what I haven't been able to find a straight answer on is why. Instead, the web is apparently filled with people who blindly change the rewrite to use a query string (e.g. changing the index.php/$1 portion of the above to index.php?/$1 - note the ?) without actually understanding the underlying problem.

I know that the issue is occuring as a part of, or as a result of, the rewriting process, and that it is not a problem of FastCGI installs being unable to handle PATH_INFO URLs at all, since the $_SERVER['PATH_INFO'] variable is populated appropriately when I navigate directly to without going through the rewrite process.

Could someone please explain what is happening during the rewrite and subsequent hand-off to PHP that is causing the failure?

share|improve this question

I found two different informations about this in PHP documents.

First one is in php.ini page about cgi.fix_pathinfo option.

cgi.fix_pathinfo boolean

Provides real PATH_INFO/ PATH_TRANSLATED support for CGI. PHP's previous behaviour was to set PATH_TRANSLATED to SCRIPT_FILENAME, and to not grok what PATH_INFO is. For more information on PATH_INFO, see the CGI specs. Setting this to 1 will cause PHP CGI to fix its paths to conform to the spec. A setting of zero causes PHP to behave as before. It is turned on by default. You should fix your scripts to use SCRIPT_FILENAME rather than PATH_TRANSLATED.

And second one is in server variables page. It is related with previous info.


Filesystem- (not document root-) based path to the current script, after the server has done any virtual-to-real mapping.

Note: As of PHP 4.3.2, PATH_TRANSLATED is no longer set implicitly under the Apache 2 SAPI in contrast to the situation in Apache 1, where it's set to the same value as the SCRIPT_FILENAME server variable when it's not populated by Apache. This change was made to comply with the CGI specification that PATH_TRANSLATED should only exist if PATH_INFO is defined. Apache 2 users may use AcceptPathInfo = On inside httpd.conf to define PATH_INFO.

You can try disabling MultiViews in apache conf. It may also cause this.

share|improve this answer
I've seen the cgi.fix_pathinfo setting mentioned elsewhere but, as the manual says, it's enabled by default. I've toyed with turning both that setting and MultiViews on and off, but none have fixed the issue. I'm not so worried about fixing it, since I do have workarounds, so much as I was wondering what in the apache->php handoff is causing the issue in the first place. – AgentConundrum Jan 9 '12 at 7:06

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.