[GH-ISSUE #1096] Returned http status after uncaught exception #447

New issue

Closed

opened 2026-03-04 02:15:06 +03:00 by kerem · 5 comments

kerem commented

2026-03-04 02:15:06 +03:00

Owner

Originally created by @ralphiech on GitHub (Dec 14, 2017).
Original GitHub issue: https://github.com/Seldaek/monolog/issues/1096

Hi @Seldaek

I just ran into an issue where I noticed that the ErrorHandler essentially prevents the original behaviour of PHP (returning HTTP status code 500) and instead returns with a 200. Any chance we could return a 500 here? Am happy to send you a patch if you like and agree with me.

Thanks

github.com/Seldaek/monolog@7b99283627/src/Monolog/ErrorHandler.php (L168)

Originally created by @ralphiech on GitHub (Dec 14, 2017). Original GitHub issue: https://github.com/Seldaek/monolog/issues/1096 Hi @Seldaek I just ran into an issue where I noticed that the ErrorHandler essentially prevents the original behaviour of PHP (returning HTTP status code 500) and instead returns with a 200. Any chance we could return a 500 here? Am happy to send you a patch if you like and agree with me. Thanks https://github.com/Seldaek/monolog/blob/7b992836275e09ed63c63fe33ca9993e515e6c5d/src/Monolog/ErrorHandler.php#L168

kerem

2026-03-04 02:15:06 +03:00

closed this issue
added the
Bug
label

kerem commented

2026-03-04 02:15:07 +03:00

Author

Owner

@Seldaek commented on GitHub (Jan 4, 2018):

Would you add a header() call before the exit()? That sounds reasonable to me, as long as you check that headers aren't sent yet otherwise that'll trigger another error.

@Seldaek commented on GitHub (Jan 4, 2018): Would you add a header() call before the exit()? That sounds reasonable to me, as long as you check that headers aren't sent yet otherwise that'll trigger another error.

kerem commented

2026-03-04 02:15:07 +03:00

Author

Owner

@hinrik commented on GitHub (Jan 18, 2018):

@ralphiech's coworker here. The referenced pull request resolves the issue for us.

@hinrik commented on GitHub (Jan 18, 2018): @ralphiech's coworker here. The referenced pull request resolves the issue for us.

kerem commented

2026-03-04 02:15:07 +03:00

Author

Owner

@hinrik commented on GitHub (Jan 19, 2018):

Actually, after considering other projects where we use Monolog, this patch would be too limiting for us. There are cases where we want to return a response code of 200 even when an exception has been raised, but since the upstream code immediately calls exit(255), that's not something we can easily work around (e.g. with a subclass).

We'd have to manually set the response code and send output to the client sometime before any exception would be raised. The patch also wouldn't play well with PHP setups that have display_errors enabled.

@hinrik commented on GitHub (Jan 19, 2018): Actually, after considering other projects where we use Monolog, this patch would be too limiting for us. There are cases where we want to return a response code of `200` even when an exception has been raised, but since the upstream code immediately calls `exit(255)`, that's not something we can easily work around (e.g. with a subclass). We'd have to manually set the response code and send output to the client sometime before any exception would be raised. The patch also wouldn't play well with PHP setups that have `display_errors` enabled.

kerem commented

2026-03-04 02:15:07 +03:00

Author

Owner

@ralphiech commented on GitHub (Jan 19, 2018):

@Seldaek if you want to add it you probably need to check if headers are sent as well as that display_errors are off (!headers_sent() && ini_get('display_errors') === 0) and only then force 500. In this case this should restore the original php behaviour, however as @hinrik said for now we don't need the change and we are not sure what is better to add this change or keep the behaviour due to people using it that way.

@ralphiech commented on GitHub (Jan 19, 2018): @Seldaek if you want to add it you probably need to check if headers are sent as well as that display_errors are off `(!headers_sent() && ini_get('display_errors') === 0)` and only then force 500. In this case this should restore the original php behaviour, however as @hinrik said for now we don't need the change and we are not sure what is better to add this change or keep the behaviour due to people using it that way.

kerem commented

2026-03-04 02:15:07 +03:00

Author

Owner

@ralphiech commented on GitHub (Jan 26, 2018):

Sorry for the forth and back @Seldaek we concluded that it would be the right thing to restore the default php behaviour just before the exit. Obviously its up to you if you want to merge it, both works for us. Cheers.

@ralphiech commented on GitHub (Jan 26, 2018): Sorry for the forth and back @Seldaek we concluded that it would be the right thing to restore the default php behaviour just before the exit. Obviously its up to you if you want to merge it, both works for us. Cheers.