2

1 つのページで、複数の AJAX 呼び出しを行っています。すべての呼び出しは正常に応答を返しますが、最後の呼び出し (他の ajax 呼び出しとは関係ありません) は応答コードとして 500 内部サーバー エラーを返します (firebug が示すように)。ただし、エラー コードにもかかわらず、その AJAX 呼び出しから正しいコンテンツが返されます。

驚いたことに、php.ini で display_errors オプションを On に設定すると、エラーが消え、ページに応答が表示されます。ファイルへのエラー ログを設定しましたが、上記の内部サーバー エラーに対応するエラーがログに記録されません。

ちなみに、私はApache、JQuery、PHP5、APCを使用しています（関連する場合）。

4

6 に答える 6

2

それは非常に奇妙です...実際の戻り値とは関係なく、ステータスコードヘッダーに影響を与える可能性のある、作成していないある種のライブラリまたはその他のコードを使用していますか?

于 2009-07-26T08:10:09.557 に答える
0

この問題は、多くの場合、次のイオンによって修正されます。スクリプトのアクセス許可、権利、および所有権を確認してください。ajax 呼び出しの後に返された場合は、致命的なエラーがどこにもないかどうかを確認します。ファイルを ASCII モードで誤って Unix にアップロードしていないかどうかを確認してください。

詳細については、http://www.larshemel.com/forum/500_internal_server_errorをご覧ください。

于 2010-08-10T16:05:53.773 に答える
0

私はやや似たような問題を抱えていましたが、問題はスクリプトが例外をスローしていて、catch ブロックがなかったため、例外が表面に出て、致命的なエラー「キャッチされていない例外」が発生したことでした。これは PHP の標準的な動作ですが、ある特定のサーバーでは、200 OK ではなく 500 内部サーバー エラーの応答コードも取得します。例外を削除し、それらを die() ステートメントに置き換えることで、そのサーバーの問題が修正されました (そもそも例外の恩恵を受けない単純なスクリプトだったので、それを行うことができました)

于 2009-10-28T18:19:25.900 に答える
0

PHP インタープリターは、この 1 つの要求中に単純にクラッシュします。PHP がクラッシュする可能性のある 1 つの潜在的な理由を知っています。

GCC 4.3 のいくつかのバグにより、このバージョンのコンパイラでコンパイルされた PHP では例外の実装が壊れています。いくつかの重要なケースでは、スクリプトによって例外がスローされると、segfault が発生し、スクリプトの実行が終了します。この論文は、数か月前に PHP チームによって確認されました。

それが発生したかどうかを確認するには、スクリプトの実行がどこでクラッシュするかを簡単に確認できます。例外がスローされた直後に発生した場合は、自宅にいます。チェックはdie()、スクリプトにさらに追加して実行することで実行でき、何が起こるかを確認できます。もう 1 つの方法は、ティックごとにdeclare(ticks=1)最後のエントリをファイルに保存するティック関数を使用して登録することです。これにより、スクリプトの実行方法に関するレポートを取得できます。debug_backtrace()

于 2009-07-26T08:39:30.027 に答える