Unexpected clearing of $_SERVER superglobal when accessing $_ENV in PHP-FPM
まだ誰も着手していません。
- 主要言語
- C
- スター
- 40.4k
- フォーク
- 8.1k
- 平均マージ
- 2日 13時間
- マージ済み PR(30日)
- 96
説明
Description
Summary:
When using PHP-FPM, accessing the $_ENV superglobal with filter_var() or directly can cause the $_SERVER superglobal to lose its values, specifically REMOTE_ADDR, which unexpectedly becomes null. Notably, this occurs even if the code accessing $_ENV is placed after an exit, which should prevent it from executing. This behavior does not occur when using PHP with other SAPIs, such as Apache’s mod_php.
Steps to Reproduce:
- Create a PHP script with the following content:
<?php
$remoteAddr = filter_input(INPUT_SERVER, 'REMOTE_ADDR', FILTER_VALIDATE_IP);
if ($remoteAddr === null) {
echo 'REMOTE_ADDR is not set';
} elseif ($remoteAddr === false) {
echo 'Invalid IP address';
} else {
echo "IP Address: $remoteAddr";
}
exit;
// Accessing $_ENV with filter_var, which should not execute due to the exit above
$appEnv = filter_var($_ENV['APP_ENV'], FILTER_SANITIZE_SPECIAL_CHARS);
-
Run this script using PHP-FPM with either Nginx or Apache as the reverse proxy.
-
Expected Behavior: The script should display the client’s IP address from
$_SERVER['REMOTE_ADDR']and then terminate execution after theexitstatement, meaning the code below exit should never be executed or have any effect. -
Actual Behavior: The script displays "REMOTE_ADDR is not set", indicating that
$_SERVER['REMOTE_ADDR']is unexpectedlynull, despite the exit command being in place. This suggests that simply having thefilter_var($_ENV['APP_ENV']...line in the script is enough to cause this behaviour, even though the line should never actually run due to theexit. -
Modify the script to use
filter_inputfor$_ENV:
$appEnv = filter_input(INPUT_ENV, 'APP_ENV', FILTER_SANITIZE_SPECIAL_CHARS);
- Observed Behaviour: When filter_input is used instead of directly accessing
$_ENV, the issue does not occur, and$_SERVER['REMOTE_ADDR']is correctly set, even though this line should not execute due to the preceding exit.
Question:
Is this behavior expected when using PHP-FPM, or is it a quirk that should be addressed? The fact that this occurs even with the exit command in place suggests there might be an underlying issue in how PHP-FPM manages superglobals. If it’s expected, could it be documented more clearly to avoid confusion for developers relying on superglobals like $_SERVER and $_ENV?
PHP Version
PHP 8.3.10, observed down to PHP 5.6.40
Operating System
No response
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず、記載されているスクリプトとバージョンを使って PHP-FPM で動作を再現し、その後、Apache mod_php などの別の SAPI と比較します。filter_var() または $_ENV への直接アクセスが $_SERVER および REMOTE_ADDR とどのように関係するかを追跡し、既存の FPM とスーパーグローバルのテストを確認します。動作が説明され、修正またはドキュメント化され、終了ケースのカバレッジが追加されていれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- c, php
- 領域
- backend
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 32/100