PATH_INFO是一個CGI 1.1的標準，經常用來做為傳參載體. 比如, 我們可以使用PATH_INFO來代替Rewrite來實現偽靜態(tài)頁面, 另外不少PHP框架也使用PATH_INFO來作為路由載體.
在Apache中, 當不加配置的時候, 對于PHP腳本, AcceptPathInfo是默認接受的, 也就是說:
如果在服務器在存在一個/laruence/index.php
那么, 對于如下請求,
/laruence/index.php/dummy
/laruence/dumm
Apache都接受, 都會認為是對info.php的訪問, 并會設置PATH_INFO為dummy
而對于Nginx下, 是不支持PATH INFO的, 也就是它不會默認設置PATH_INFO.
而因為默認的配置文件對PHP的支持只是很基礎的, 所以對于默認配置來說對于上面的訪問也會是404, 提示找不到文件出錯.
這對于一些使用PATH_INFO來傳遞關鍵信息的PHP框架來說(比如Kohana, Thinkphp), 簡直是致命的.
對于這個問題, 一般來說有倆種解決方法, 第一種就是使用rewrite, 但是這個方法的缺點也是很明顯的, 需要把PATH_INFO轉換成Query String. 此處就不說明這種方法了~
而, 第二種方法就是我今天要提的, 模擬PATH_INFO:
首先 , 我們知道在Nginx中, 是通過對文件名的擴展名匹配, 來決定是否要交給php cgi服務器去解釋的. 在nginx.conf中一般都有如下的默認配置段:
location ~ .php$ {
fastcgi_index index.php;
fastcgi_pass 127.0.0.1:9000;
include fastcgi_params;
所以,對于形如/laruence/info.php/pathinfo這樣的文件路徑, Nginx是不會正確的交給php cgi服務器的. 所以我們需要改寫這段配置為:
location ~ .php {//片段匹配
fastcgi_index index.php;
fastcgi_pass 127.0.0.1:9000;
include fastcgi_params;
現在, 腳本路徑已經交由PHP自己處理了. 那怎么增加PATH_INFO呢?
首先, 我們需要打開PHP中cgi.fix_pathinfo配置項, 打開這個配置項以后, PHP會去根據CGI規(guī)范來檢查SCRIPT_FILENAME中那部分是訪問腳本和PATH_INFO(ini配置解釋), 并根據SCRIPT_NAME來修改PATH_INFO(和PATH_TRANSLATED)為正確的值(其實也就是說明, PHP最初對CGI 1.1的支持并不到位)
然后, 就只要添加一個FASTCGI_PARAM項就好了:
location ~ .php {
fastcgi_index index.php;
fastcgi_pass 127.0.0.1:9000;
include fastcgi_params;
fastcgi_param PATH_INFO $fastcgi_script_name;
現在試試吧…
btw: 當然, 上面的解決方法, 把對路徑的分析交給了PHP去處理, 網上也有朋友給出了另外一種配置方法, 這個方法是由Nginx來分析路徑(也就不需要fix_pathinfo):
location ~ /.php
{
fastcgi_index index.php;
fastcgi_pass 127.0.0.1:9000;
include fastcgi_params;
set $path_info "";
set $real_script_name $fastcgi_script_name;
if ($fastcgi_script_name ~ "^(.+?/.php)(/.+)$") {
set $real_script_name $1;
set $path_info $2;
}
fastcgi_param SCRIPT_FILENAME /var/html/$real_script_name;
fastcgi_param SCRIPT_NAME $real_script_name;
fastcgi_param PATH_INFO $path_info;
后記, 最近發(fā)現的一個安全漏洞(Nginx + PHP CGI的一個可能的安全漏洞)和這個配置有關系, 請大家務必在使用第二種配置的時候,關閉cgi.fix_pathinfo. 另外關于這個漏洞我個人認為這個和Nginx沒啥關系, 不屬于Nginx的漏洞. 是配置的問題, 現在到處都在說是Nginx的Bug, 不妥不妥.
