当请求Plupload时，“Load-scripts.php”挂起并超时

我对Wordpress有一个令人困惑的问题。当/admin/load下的页面以“plupload”作为参数之一加载“load scripts.php”时，它将永远挂起。“添加新帖子”页面就是这样一个页面。例如，此URL永久挂起：

http://example.com/wp-admin/load-scripts.php?c=0&load%5B%5D=jquery-core,jquery-migrate,utils,plupload,json2&ver=3.9.1

虽然此操作立即成功返回：

http://example.com/wp-admin/load-scripts.php?c=0&load%5B%5D=jquery-core,jquery-migrate,utils,json2&ver=3.9.1

当我说“永远挂起”时，我的意思是它挂起几分钟，最后只返回部分结果，没有错误。所谓部分结果，我指的是在表达式中间突然结束的缩小Javascript。

我使用libapache2-mod-php5在Apache上运行Wordpress版本3.9.1和3.8，使用php5 fpm在Nginx上运行，并且只使用普通的php内置开发服务器。在所有情况下，此问题仍然存在。

我已降级到3.0版，问题消失了。在这个版本中，“load scripts.php”不会试图获取plupload。由于我还没有用谷歌找到任何解决这个问题的方法，我假设这是我的服务器的问题，而不是Wordpress的bug。

使用set_time_limit 没有效果，脚本仍然永远挂起。在使用php开发服务器时，我在任何日志中以及控制台中都没有发现任何错误。

出于某种原因，将其替换为（load scripts.php的最底层）：

header(\'Content-Type: application/x-javascript; charset=UTF-8\');
header(\'Expires: \' . gmdate( "D, d M Y H:i:s", time() + $expires_offset ) . \' GMT\');
header("Cache-Control: public, max-age=$expires_offset");

if ( $compress && ! ini_get(\'zlib.output_compression\') && \'ob_gzhandler\' != ini_get(\'output_handler\') && isset($_SERVER[\'HTTP_ACCEPT_ENCODING\']) ) {
     header(\'Vary: Accept-Encoding\'); // Handle proxies
     if ( false !== stripos($_SERVER[\'HTTP_ACCEPT_ENCODING\'], \'deflate\') && function_exists(\'gzdeflate\') && ! $force_gzip ) {
             header(\'Content-Encoding: deflate\');
             $out = gzdeflate( $out, 3 );
     } elseif ( false !== stripos($_SERVER[\'HTTP_ACCEPT_ENCODING\'], \'gzip\') && function_exists(\'gzencode\') ) {
             header(\'Content-Encoding: gzip\');
             $out = gzencode( $out, 3 );
     }
}

echo $out;
exit;

使用此选项：

header(\'Content-Type: application/x-javascript; charset=UTF-8\');
header(\'Expires: \' . gmdate( "D, d M Y H:i:s", time() + $expires_offset ) . \' GMT\');
header("Cache-Control: public, max-age=$expires_offset");

// if ( $compress && ! ini_get(\'zlib.output_compression\') && \'ob_gzhandler\' != ini_get(\'output_handler\') && isset($_SERVER[\'HTTP_ACCEPT_ENCODING\']) ) {
//      header(\'Vary: Accept-Encoding\'); // Handle proxies
//      if ( false !== stripos($_SERVER[\'HTTP_ACCEPT_ENCODING\'], \'deflate\') && function_exists(\'gzdeflate\') && ! $force_gzip ) {
//              header(\'Content-Encoding: deflate\');
//              $out = gzdeflate( $out, 3 );
//      } elseif ( false !== stripos($_SERVER[\'HTTP_ACCEPT_ENCODING\'], \'gzip\') && function_exists(\'gzencode\') ) {
//              header(\'Content-Encoding: gzip\');
//              $out = gzencode( $out, 3 );
//      }
// }

echo "SUCCESS";
exit;

echo $out;
exit;

使脚本立即返回“SUCCESS”。如果我没有注释掉压缩块，就会返回垃圾数据。很明显剧本还在继续echo $out. 我猜这个bug与压缩有关，但我不知道如何处理这些信息。

我意识到这个问题很难简单地回答，但我确信一旦我找出问题所在，就会有一个简单的解决方案。

提前感谢您的建议。

<小时>Edit: 我使用CURL进一步检查了脚本。我尝试过请求“load scripts.php”，并将“Accept Encoding”设置为gzip、deflate和nothing。这没什么区别。在所有情况下，脚本都会立即返回一组数据，然后在Javascript语句中间冻结。对于每个请求，它似乎都会在输出Javascript中的一个随机位置停止。我已经启用了所有错误报告，并将允许内存设置为2048M，这也完全没有影响。我开始认为这里有一些低级PHP问题，我无法解决。

<小时>New edit: 我做了进一步的实验。结果是如果我var_dump($out); 和exit; 就在之后$out 构建后，脚本仍挂起。这一定与打印字符串的大小有关（216459个字符）字符串的一部分被发送到浏览器，然后请求只是挂起（在一种情况下长达6分钟），然后就消失了，而没有输出字符串的其余部分。任何地方都没有报告错误。

<小时>Yet another edit: 我已将此放在脚本的顶部：

header(\'Content-Type: application/x-javascript; charset=UTF-8\');
header(\'Expires: \' . gmdate( "D, d M Y H:i:s", time() + $expires_offset ) . \' GMT\');
header("Cache-Control: public, max-age=$expires_offset");
var_dump(str_repeat("foo", 350000));
exit;

1050 000个字符的str可以快速成功地发送到浏览器，而不会出现问题。这与输出大小无关。

小码农CODE

相关推荐

Debug Performance Issues