Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#15539 closed (needsinfo)

Django shows traceback even when debug is false

Reported by: phektus@… Owned by: Arbie Samong
Component: Uncategorized Version: 1.2
Severity: Keywords: exception 500 debug
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I had an error in urls.py, which threw an exception. Now the site is in production, and debug is set to false. I have custom 400 and 500 pages. Now I know I can easily check that sort of error in a local setup, but shouldn't there be no traceback information whatsoever when debug is false?

Just put some erroneous code or throw and exception in urls.py to reproduce.

Change History (2)

comment:1 by Karen Tracey, 13 years ago

milestone: 2.0
Resolution: needsinfo
Status: newclosed

What are you using for your production server? If I put an error in base urls.py on a test Apache/mod_wsgi served project, I get Apache's "Internal Server Error" page (the traceback is logged in the Apache error log, not shown on the requesting browser). I've seen more sophisticated wsgi scripts for production which catch any exceptions raised by the wsgi application and present a pretty error page in place of Apache's plain Internal Server Error page. Essentially there are always going to be cases of errors thrown that are not covered by Django's 500 handler...and your production server configuration needs to be set up properly to ensure that what's sent back to the browser in that case is what you want.

Removing the 2.0 milestone because that's meant for stuff that we'd like to do at some point but will cause backwards-compatibility problems, and this issue wouldn't have backwards compatibility problems. There's no reason improvements to error handling would need to wait until 2.0 timeframe. Closing needsinfo because maybe there is a case to be made that the 500 handler should be covering cases like errors in urls.py, but someone would need to investigate whether that's feasible. My first thought is that's a case that needs to be handled by the production server config.

comment:2 by anonymous, 13 years ago

I actually tested it off the default vanilla server (manage.py runserver), not sure of any other production setups that would do a similar behavior. I think you're right, apache would handle this well as compared to the default server, which shouldn't be used in a production space in the first place.

Note: See TracTickets for help on using tickets.
Back to Top