6

これはあまりにも曖昧な質問かもしれませんが、私は不可解なサーバー エラーのトラブルシューティングを何時間も行っており、最も奇妙な問題に突き止めました。この時点で、誰かが似たようなことが起こったことがあるかどうか、または何が起こっている可能性があるかについての洞察を持っているかどうかを知りたいだけです.

次のコード行がエラーを引き起こしています。

if ($Name=='ProxiedIP') { return true; }

このバージョンはまったく問題なく動作します:

if ($Name=='proxiedIP') { return true; }

どういうわけかトークン「ProxiedIP」が何かを汚しているように見えますが、このようにサーバーをハングアップさせる方法で文字列リテラルがパーサーによってどのように変換されるかさえ考えられません。ところで、私は確かに$Name!='proxiedIP'と$Name!='ProxiedIP'を知っています。

Apache エラー ログのエントリは次のとおりです。

[Fri Jan 18 18:15:12.924419 2013] [core:error] [pid 27676:tid 3427232831232] [client 12.345.67.890:34482] Premature end of script headers: index.php, referer: http://mySite.com/

システムで考えられるすべてのコンポーネントのキーワードとして「ProxiedIP」を検索しましたが、何も思いつきません。ただし、私にとってより重要な質問は、文字列が比較チェックでこのような影響を与える方法です。何か案は？

また、PHP エラー ログがそれについて完全に沈黙していることも注目に値します。ページの上部でエラー出力を有効にしていますが、スクリプトの読み込みが完了しないため、それが原因である可能性があります。設定方法は次のとおりです。

error_reporting(E_ALL);
ini_set('display_errors', 1);

コードはここで機能したため、プラットフォームの実装に固有のものである可能性が高くなります。これは、アプリケーション アクセラレーションのために Varnish を実行する Gandi.net の「Simple Hosting」サービスのインスタンスで実行しています。コードが別のドメインの iframe に読み込まれていることにも言及する価値があるかもしれません。

私はまた、ヘッダーでいくつかの集中的な作業を行っています。これが問題の最大の潜在的な原因のようですが、私に関する限り奇妙なことは、エラーがトリガーされる方法です. また、私が認識している「ProxiedIP」と呼ばれる一般的なヘッダーはありません。とにかく、私はそれを見ません。

私にとって、関連性のある実際の項目は、文字列の比較がサーバーをクラッシュさせているという単なる事実です。私は 10 年以上 PHP でプログラミングを行っていますが、このようなことはこれまで一度もありませんでした。私は、それがどのように起こり得るかの背後にあるロジスティクスを理解しようとしています.

更新: 次のバリエーションを試しましたが、それでも同じ結果が得られます。

if ($Name === (strtoupper("p").'roxiedIP')) { return true; }

完全なコードを投稿するかどうか尋ねられましたが、iframe 側のスクリプトは 1400 行以上あるため、実際には実行できません。問題のセグメントを新しいスクリプトで実行するように調整していますが、結果を投稿します。

4

4 に答える 4

2

問題は変数 $Name にあると思います。正しく割り当てられているか確認してください。また、問題の原因となっている if ステートメントの後のコードも確認してください。

于 2013-01-19T08:57:14.800 に答える
1

投稿に感謝しますが、関数チェーンの数レベル下の条件が問題の関数の範囲外で予期しない動作を引き起こす、非常に複雑なシナリオであることが判明しました。

実際の問題は、完全に別のプロセスで debug_backtrace() 配列の出力を解析する際の条件チェックが原因でした。これは、皮肉なことに、無限再帰を防ぐために配置され、代わりに、割り当てられたメモリ制限をオーバーランする同様の破壊的なイベントのカスケードをトリガーしました。

私が最初に投稿したのは、文字列リテラルの比較が可能だとは思わないことを実際に行っているように見えたことに困惑し、可能であればどのような条件でそれが可能になるかを理解したかったからです。原因が実際には思っていたものではなくてよかったです。パズルの解決にご協力いただきありがとうございます。

更新: エラーの真の原因は、それ自体への参照を含むオブジェクトまたは配列を PHP が変換するのが難しいことにかかっています。変換されたヘッダー、ヘッダーの直接参照、$_REQUEST[] および $_SERVER[] アイテムを格納し、ログ メッセージと関連データを複雑な連想配列に格納しています。これらの項目の間には多くの動的参照があり、特に私が利用したネイティブ PHP グローバルを含むものです。

PHP は伝統的に、自己参照エンティティの管理に問題を抱えていました。改善は行われましたが、私の特定の状況は非常に複雑で、これらのオブジェクトをマップしようとしている間にReflectionClassを無限ループに送り込んでしまいます。アイテムをポーリングしているときにアイテムを手動で逆参照することで修正しましたが、共通の配列または参照構造内で複数の $GLOBALS 関連の変数を操作する必要がある場合は注意が必要です。

于 2013-01-19T19:21:09.293 に答える
1

私があなたのエラーから得たように、あなたはフレームワークを台無しにしています.fwが出力を許可する前に、あなたのifの変更が何らかの出力が呼び出されることを引き起こします. 詳細を読んでください。間違った列車に乗っていました。それはエラーの原因ではありません。fw の不浄な状態の始まりです。

var dump を使用するのではなく、php デバッガーでスクリプトを実行してみてください。

于 2013-01-19T01:01:52.743 に答える
1

実際、あなたの問題は呼び出し元の関数にあると思います。つまり、戻り値に応じて「ばかげた」ことを行い、PHP がクラッシュします。if() をハードreturn trueorに置き換えてみて、return false何が起こるか見てみましょう。

于 2013-01-19T00:01:49.330 に答える