Opened 8 years ago

Closed 8 years ago

Last modified 5 years ago

#7471 closed (fixed)

Django serves exception tracebacks from 404 handlers

Reported by: trevor Owned by: leahculver
Component: Core (Other) Version: master
Severity: Keywords:
Cc: Triage Stage: Ready for checkin
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


Django will serve an exception traceback if your 404 handler raises an exception. The relevant part of django.core.handlers.base follows:

except http.Http404, e:
    if settings.DEBUG:
        from django.views import debug
        return debug.technical_404_response(request, e)
        callback, param_dict = resolver.resolve404()
        return callback(request, **param_dict)

If resolve404() raises any exception (such as an invalid block tag in the 404 template, or if the user has overriden handler404), Django does not suppress the exception and serve a 500 page; instead it simply serves the traceback. Note that this happens even if DEBUG is set to False.

This might catch someone by surprise if they launch their site without checking if 404 pages work with DEBUG turned off (i.e., they would see a traceback from this issue, but be expecting it).

Attachments (1)

patch-7471-no-tests.diff (1.6 KB) - added by leahculver 8 years ago.
return handle_uncaught_exception for errors with the 404 handler

Download all attachments as: .zip

Change History (10)

comment:1 Changed 8 years ago by programmerq

  • Triage Stage changed from Unreviewed to Accepted

comment:2 follow-up: Changed 8 years ago by garcia_marc

  • milestone set to 1.0

That's correct. And couldn't be difficult to fix. The problem that I found is what to do if the error exists in the 500 template.

comment:3 in reply to: ↑ 2 Changed 8 years ago by MihaiD

I think we need to define a hardcoded 500 template somewhere and use it as a last resort.

comment:4 Changed 8 years ago by leahculver

  • Owner changed from nobody to leahculver
  • Status changed from new to assigned

comment:5 Changed 8 years ago by Karen Tracey <kmtracey@…>

Possibly related: #6094. It has a pretty comprehensive patch to attempt to prevent exception tracebacks leaking out, but I don't know if it covered this case.

Changed 8 years ago by leahculver

return handle_uncaught_exception for errors with the 404 handler

comment:6 Changed 8 years ago by leahculver

  • Triage Stage changed from Accepted to Ready for checkin

Modified get_response to handle 404 handler errors (handler404 view) with a generic 500 error. This displays the 500 page instead of a stack trace.

This is very difficult to write a stable test case for since it involves adding a custom handler404 that throws an exception in the root This is easy to do by pointing handler404 to a view that does not exist. However, this is not a good thing to add to the test suite since it would mess up other test cases. I've tested this manually and Malcolm (mtreddinick) is okay with it not having a test case.

comment:7 Changed 8 years ago by leahculver

Karen - I think this falls in the general category of "exceptions that should be prettier" but isn't fixed by #6094.

comment:8 Changed 8 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [7988]) Fixed #7471 -- If the 400 response handler raises an exception, pass control to
the 500 handler (if that then raises an exception, it's just not your day).

Patch from Leah Culver.

comment:9 Changed 5 years ago by jacob

  • milestone 1.0 deleted

Milestone 1.0 deleted

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