标签： RFC

nginx上，http状态200响应，PHP空白返回的问题

nginx上，http状态200响应，PHP空白返回的问题

最近的大半年中，编程语言从PHP换到了Golang后，就很少接触PHP，当然，更多的还是恋恋不舍。尽管如此，每当有人在群里聊起PHP的话题时，我总是想插几句，怀念怀念，同时也温故温故知识点，可不能把她给忘了。昨天朋友tywei问我一个关于PHP奇怪问题，查到原因解决后，没有详细的解释。夜里睡觉时，老是回想这事，早上醒来，决定还是认真记录一下这些问题。也让自己回归正常状态，多写点博客，总结自己，记录自己。问题描述 PHP+nginx的环境，任何PHP处理的结果，都是空白页面。OS是ubuntu 14.10 ，nginx 1.6.2 ,PHP5.5.12, 问任何PHP的页面，返回的HTTP状态200，但页面内容是空的，什么都没有，不管PHP页面里写的是什么，正常响应。初步怀疑这是拓展的问题，处理请求后，输出内容有冲突，输出为空之类。想查看拓展列表，看看加载了哪些拓展，但任何PHP代码都返回空，万不得已，在CLI模式下运行，确定ini是同一个。粗略的看了加载的模块，列表如下：大约如上的模块加载，怀疑xdebug跟opcache冲突，尝试关闭后，仍未解决。 strace看系统调用信息觉得好简短，好奇怪,访问的是SCRIPT_NAME index.php，怎么都没 lstat \open 这个PHP文件呢？直接返回了？起码要判断SCRIPT_FILENAME是否存在吧，要读取SCRIPT_FILENAME，解析里面的代码吧？等下.....SCRIPT_FILENAME全部地址是啥？发来的CGI协议包中怎么没有SCRIPT_FILENAME？仔细看下CGI包的内容缺少：那么问题来了 PHP-FPM接收CGI请求时，如果没有SCRIPT_FILENAME怎么处理的？发来的CGI协议包中，为啥没有SCRIPT_FILENAME？（SCRIPT_FILENAME是什么，干啥用的，这个就不要问了吧。）问题1：PHP-FPM接收CGI请求时，如果没有SCRIPT_FILENAME怎么处理的？ fpm源码里（PHP5.5.x 为例）同样是 fpm_main.c中init_request_info函数的代码如下：从代码里看出，script_path_translated变量就是cgi协议包中SCRIPT_FILENAME的结果，其中1115行左右，判断如果script_path_translated为空，并且env_path_translated不为空，则用env_path_translated赋值到script_path_translated上。之后，对request_info的几个属性给予了默认值，包括request_method为null，以及http_response_code默认200的http响应。在后面的代码中if (script_path_translated) ，因为CGI包中没有SCRIPT_FILENAME，也没有PATH_TRANSLATED，即script_path_translated为空，故没有对request_method进行赋值，其默认值为NULL。回到main函数中1839行附近if (!SG(request_info).request_method) ，则直接goto到了fastcgi_request_done，直接结束当前request请求，由于之前有设置过默认的http 响应状态为200 ，也就导致了每次返回http状态200成功响应的空白页面的问题。同时也解释了strace系统调用中，没出现lstat、open 操作SCRIPT_FILENAME的记录了。问题2，发来的CGI协议包中，为啥没有SCRIPT_FILENAME？ PHP-FPM接收到的CGI协议包都是来自前面nginx的，cgi协议包中没有这个，肯定是nginx没发来，查看nginx配置看到fastcgi_params中没有这项。加上后就可以了。解决办法：在nginx配置的 fastcgt_params中加上SCRIPT_FILENAME的配置（在ubuntu的apt-get形式安装nginx配置中，默认是有这条的），比如题外话：在FPM的fpm_main.c文件的main函数中，1848行对SG(request_info).path_translated的判断，晚于1849行SG(request_info).request_method的判断。而在init_request_info函数中，对SG(request_info).path_translated的赋值却是比SG(request_info).request_method早的。而且，明明找不到需要执行的脚本，却还返回200的http响应，很奇怪，也不方便排查。我觉得把对SG(request_info).request_method的判断放到SG(request_info).path_translated后面更合适一些。或者若找不到SCRIPT_FILENAME的话，http响应状态改为404，同时，写入LOG日志，便于排查。后记：从fpm代码里可以看到，其实作者是有考虑到没有SCRIPT_FILENAME的问题的，只是判断顺序搞错了。所以，我觉得这应该是个bug，就提了一下：BUG #69625：php-fpm return http 200 response on nginx without SCRIPT_FILENAME，不知道官方是否认为这是个BUG。新的问题：为什么如果SCRIPT_FILENAME不存在时，用PATH_TRANSLATED来代替它？PATH_TRANSLATED是每个CGI前端都要发送的吗？这个问题，后来认真看了下，感觉还挺复杂，跟CGI客户端有关，PHPFPM针对IIS\APACHE\NGINX的处理都不一样。以后再写吧。参考资料： RFC3875 - The Common Gateway Interface (CGI) Version 1.1 如果你在阅读PHP源码，或者阅读PHP SAPI、PHP拓展源码，可以关注一下PHP源码执行流程图关于FPM的执行流程，可以看下下面这幅图： 2018年07月09日更新： Fix bugs #75120 and #69625 #3226里修复了我在2015年3月提的 bug report Fix bug #69625 php-fpm return http 200 response without SCRIPT_FILENAME #1270

2015-05-05

+3 7 0

最新评论

jeffrey

支持抓取emqx的tls报文么？

w3b5h3ll

不抛弃，不放弃

Zz

可以认为是代理功能吗？最近也在调研这个功能。大鹅项目好像是有类似的逻辑，dns配置 fallback 默认走代理。《ht

CFC4N

参考： https://github.com/gojue/ecapture/discussions/308

Wayne

你好，安卓上想使用eCapture,需要linux内额版本>=5.5 ,目前手上设备只有pixel 5 ,看官方的