0

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 www.example.com/index.php/foobar 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?

AgentConundrum
  • 211
  • 4
  • 12

1 Answers1

1

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. http://php.net/manual/en/ini.core.php

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

'PATH_TRANSLATED'

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. http://php.net/manual/en/reserved.variables.server.php

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

Community
  • 1
dirigeant
  • 221
  • 1
  • 4
  • 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 09 '12 at 07:06