Closed
Bug 395560
Opened 18 years ago
Closed 18 years ago
httpd.js should provide debugging information when an internal error (500) occurs
Categories
(Testing :: General, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: asqueella, Unassigned)
Details
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•18 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.
Reporter | ||
Comment 2•18 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:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/netwerk/test/httpserver/httpd.js&rev=1.10&mark=1567-1572#1550
Reporter | ||
Comment 3•18 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.
Reporter | ||
Comment 4•18 years ago
|
||
OK, so I did summarize my original problem poorly, but now you know what this bug is about :)
Comment 5•18 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.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 6•18 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?
Updated•17 years ago
|
Component: Testing → httpd.js
Product: Core → Testing
QA Contact: testing → httpd.js
Assignee | ||
Updated•7 years ago
|
Component: httpd.js → General
You need to log in
before you can comment on or make changes to this bug.
Description
•