bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

httpd.js should provide debugging information when an internal error (500) occurs



11 years ago
2 months ago


(Reporter: Nickolay_Ponomarev, Unassigned)


Windows XP

Firefox Tracking Flags

(Not tracked)




11 years ago
Debugging bug 395559 took more time than I would have liked, because the code in httpd.js catches all possible exceptions and rethrows them as a generic HttpError with code 500 without even logging the original exception. This is not cool.

It should log any exceptions it catches, and optionally (when DEBUG is set?) return them in the response like other servers do.

Comment 1

11 years ago
The intent has always been that if you need to know exactly what's happening in the server, you flip the DEBUG flag and watch console output.  See, for example, the server tests' head_utils.js, which sets DEBUG to true so the output from the test can diagnose the error.  The error pages were never meant to be interesting or super-informative (and in a real server they wouldn't be anyway, because the errors could expose information that might make the server easier to attack), and DEBUG was always the way to get more info.

I don't think this should be fixed, but feel free to try and convince me otherwise.

Comment 2

11 years ago
OK, maybe I was unfair about the code in general, but in the particular case of the second typo of bug 395559 I didn't manage to get any useful error message from this code.

I can't verify this now, but I think it's because this code never reports the actual exception:

Comment 3

11 years ago
And this bug was about this specific issue, but since you commented on this, I think it's more convenient to display the specific errors in the browser itself than making people look in the console. This of course should only happen in the development mode, but it should be possible. But again, this is out of scope of this bug.

Comment 4

11 years ago
OK, so I did summarize my original problem poorly, but now you know what this bug is about :)

Comment 5

11 years ago
It may be more convenient, but I don't think it's that much better, and I still think the don't-expose-too-much-information concern is important, even if for current use cases it doesn't matter.

I added a dumpn that should be hit for errors not caused by the server explicitly deciding to display a 500 error page; I think this is sufficient to make misbehaviors more debuggable, particularly with a note about turning on debugging added to the server page on MDC.  I don't think we should display errors in the browser error pages, and I don't think I'm likely to change my mind, so I'm marking this WONTFIX.
Last Resolved: 11 years ago
Resolution: --- → WONTFIX

Comment 6

11 years ago
Um, so as far as I can see, if DEBUG is false, the developer can't see any exceptions when things fail. I don't think anyone would want to set DEBUG to false given this. Perhaps exceptions should be reported no matter what?
Component: Testing → httpd.js
Product: Core → Testing
QA Contact: testing → httpd.js


2 months ago
Component: httpd.js → General
Product: Testing → Testing
You need to log in before you can comment on or make changes to this bug.