我当前的主机使用FastCGI来进行PHP设置，当mod_rewrite指令redirect到带有PATH_INFO部分的URL时，这显然会导致一些问题。 例如，使用以下内容时会出现问题：
RewriteEngine on RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php/$1 在使用上述操作时，导航到重写的URL会导致PHP中的“No input file specified”错误消息，这意味着PHP没有正确传递文件进行parsing。
我已经能够从networkingsearch学习，这个问题只出现在FastCGI下运行PHP时，但我没有find一个直接的答案是为什么 。 相反，networking显然充斥着一些盲目改变重写以使用查询string（例如，将index.php/$1部分改为index.php?/$1 – 注意? ）而不真正理解底层问题的人。
我知道这个问题是重写过程的一部分，或者是重写过程的结果，并且这不是FastCGI安装无法处理PATH_INFO URL的问题，因为$_SERVER['PATH_INFO']当我直接导航到www.example.com/index.php/foobar而不经过重写过程时，variables被适当地填充。
有人可以解释什么是在重写和随后交付给PHP造成的失败？
我在PHP文档中发现了两个不同的信息。
首先是在php.ini页面中关于cgi.fix_pathinfo选项。
cgi.fix_pathinfo布尔值
为CGI提供真正的PATH_INFO / PATH_TRANSLATED支持。 PHP以前的行为是将PATH_TRANSLATED设置为SCRIPT_FILENAME，并且不理解PATH_INFO。 有关PATH_INFO的更多信息，请参阅CGI规范。 将其设置为1将导致PHP CGI修复其path以符合规范。 设置为零会导致PHP像以前一样运行。 它默认打开。 您应该修复脚本以使用SCRIPT_FILENAME而不是PATH_TRANSLATED。 http://php.net/manual/en/ini.core.php
第二个是在服务器variables页面。 它与以前的信息有关。
'PATH_TRANSLATED'
在服务器完成任何虚拟到实际的映射之后，文件系统（不是基于文档根目录的）到当前脚本的path。
注意：从PHP 4.3.2开始，与Apache 1中的情况相比，PATH_TRANSLATED不再隐式设置在Apache 2 SAPI的情况下，而Apache 1不会将其设置为与SCRIPT_FILENAME服务器variables相同的值。 这个改变是为了符合CGI规范，PATH_TRANSLATED应该只在PATH_INFO被定义时存在。 Apache 2用户可以使用httpd.conf中的AcceptPathInfo = On来定义PATH_INFO。 http://php.net/manual/en/reserved.variables.server.php
您可以尝试在apache conf中禁用MultiView。 这也可能导致这一点。