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

Status: RESOLVED WONTFIX

(Testing :: General, defect)

Description

[Nickolay_Ponomarev]

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

[Jeff Walden [:Waldo]]

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

[Nickolay_Ponomarev]

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:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/netwerk/test/httpserver/httpd.js&rev=1.10&mark=1567-1572#1550

Comment 3

[Nickolay_Ponomarev]

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

[Nickolay_Ponomarev]

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

Comment 5

[Jeff Walden [:Waldo]]

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.

Comment 6

[Nickolay_Ponomarev]

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?