奇怪的 500 内部服务器错误(firebug、php、display_errors、ajax)

发布于 2024-07-30 02:39:48 字数 299 浏览 9 评论 0原文

在一页上我正在进行多个 AJAX 调用。 所有调用均成功返回响应,但最后一个调用(与其他 ajax 调用无关)返回 500 内部服务器错误作为响应代码(如 firebug 所示)。 但是,尽管存在错误代码,该 AJAX 调用仍会返回正确的内容。

令我惊讶的是,当我将 php.ini 中的 display_errors 选项设置为 On 时,错误消失并在页面上呈现响应。 我已将设置错误记录到文件中,但没有记录与上述内部服务器错误相对应的错误。

顺便说一句,我正在使用 Apache、JQuery、PHP5、APC(如果相关的话)。

On one page I am doing multiple AJAX calls. All calls return responses successfully but the last one (not related to other ajax calls) returns 500 internal server error as response code (as firebug tells). However, in spite of error code, correct content is returned from that AJAX call.

To my amazement, when I set display_errors option in php.ini as On, the error disappears and response in rendered on the page. I have setup error logging to a file but no error is logged corresponding to the above mentioned internal server error.

By the way, I am using Apache, JQuery, PHP5, APC (if it is relevant).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

江湖彼岸 2024-08-06 02:39:48

鉴于可用信息有限,最可能的答案是 PHP 在完成对预期输出的回显后遇到致命错误。

测试:在最后执行的行中,回显一些内容。 如果该回声没有出现,那么您就知道您的 PHP 脚本在某个地方停止了。 到那时,只剩下调试和跟踪的问题了。

The most likely answer, given the limited information available, is that PHP is reaching a fatal error after it has finished echoing your expected output.

To test: in the line that gets executed last, echo something. If that echo doesn't show up, then you know that your PHP script is halting somewhere. At that point, it's just a matter of debugging and tracing.

油饼 2024-08-06 02:39:48

这很奇怪......您是否使用了某种您没有编写的库或其他代码,这些代码可能会影响状态代码标头,而与实际返回的值无关?

That's very strange... Are you using some kind of library or other code that you didn't write that might be affecting the status code header independently of the actual returned value?

冬天的雪花 2024-08-06 02:39:48

我遇到了完全相同的问题,结果是一个隐藏的致命错误。 打开display_errors,查找错误,粉碎错误,关闭display_errors(可能最好在开发中保持display_errors打开,在生产中关闭)。

I had this exact same issue, turned out to be a hidden Fatal Error. Turn on display_errors, find error, smash error, turn off display_errors (probably best to keep display_errors on for development and off in production).

顾铮苏瑾 2024-08-06 02:39:48

PHP 解释器在这一请求期间就会崩溃。 我知道可能导致 PHP 崩溃的一个潜在原因:

由于 GCC 4.3 中的一些错误,使用此版本的编译器编译的 PHP 的异常实现被破坏。 在某些重要情况下,脚本抛出异常会导致段错误并终止脚本执行。 该论文几个月前得到了 PHP 团队的确认。

要验证它是否发生在您身上,您可以简单地检查脚本执行崩溃的位置,以及如果发生在抛出异常之后,那么您就放心了。 可以通过在脚本中越来越远地放置 die() 来完成检查,看看会发生什么。 另一种方法是使用declare(ticks=1)并注册一个tick函数,该函数将每个tick中来自debug_backtrace()的最后一个条目保存到文件中,这样您就可以获取报告,了解脚本如何执行。

The PHP interpreter simply crashes during this one request. I know one potential reason that could crash PHP:

Due to some bugs in GCC 4.3, PHP compiled with this version of compiler has the implementation of exceptions broken. In some non-trivial cases, throwing an exception by the script causes the segfault and the script execution is terminated. The thesis was confirmed by PHP team a couple of months ago.

To verify, whether it happens to you, you can simply check, where the script execution crashes and if happens just after throwing an exception, you're at home. The check can be done by placing die() further and futher in the script and see, what happens. Another way is to use declare(ticks=1) and register a tick function that saves the last entry from debug_backtrace() to the file every tick, so that you'll get a report, how the script is executed.

花桑 2024-08-06 02:39:48

我遇到过一些类似的问题,问题是脚本抛出异常并且没有 catch 块,因此异常会浮出水面,并发生致命错误“未捕获的异常”。 这是标准的 php 行为,但在一台特定服务器上,您还会收到 500 内部服务器错误的响应代码,而不是 200 OK。 删除异常并用 die() 语句替换它们解决了该服务器上的问题(我们可以这样做,因为它是简单的脚本,实际上并没有从异常中受益)

I've had somewhat similar problem and the issue was that the script was throwing exceptions and there was no catch block so the exception would be bubbled to the surface and fatal error "uncaught exception" happened. Which is standard php behaviour but on one particular server you would also get response code of 500 internal server error instead of 200 OK. Removing exceptions and replacing them with die() statements fixed the problem on that server (we could do that because it was simple script that really didn't benefit from exceptions in the first place)

小…楫夜泊 2024-08-06 02:39:48

该问题通常可以通过以下方法之一解决。
检查脚本权限、权利和所有权。
如果ajax调用后返回,检查是否有致命错误。
检查您是否无意中以 ASCII 模式将文件上传到 Unix。

更多信息请访问 http://www.larshemel.com/forum/500_internal_server_error

The problem is often fixed by ione of the following.
Check the scripts permissions, rights and ownership.
If returned after an ajax call, check whether there is nowhere a fatal error.
Check whether you didn;t accidentally uplaoded the file to Unix in ASCII mode.

More info can be read at http://www.larshemel.com/forum/500_internal_server_error

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文