Opened 14 years ago
Closed 14 years ago
#13877 closed (fixed)
More documentation needed on exceptions in middlewares
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Core (Other) | Version: | 1.2 |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I have not found any documentation on the behaviour of django when an exception is raised, not from a view, but from a middleware method.
Eg. if a process_exception() raises an unexpected exception, how will django deal with that ? And if a process_response() fails when treating a normal http response ?
I can have some information by testing these tests, but as long as it's undocumented I can't really rely on it.
Change History (6)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
Looks like this could use a little DDN... is this a documentation issue or a code issue? What *is* the desired behavior here?
comment:3 by , 14 years ago
I guess the whole middleware processing should be protected by lowest-level exception handlers.
It seems that neither email sending, nor debug page processing, require the middlewares to function, anyway.
So process_response should be handled like other middleware functions - if they raise smth, catch it and trigger the critical eror system.
comment:4 by , 14 years ago
Component: | Uncategorized → Core framework |
---|
I've browsed django's core handlers modules, and there is a very weird design there. Look at that code, which is the same in modpython and wsgi handlers :
response = self.get_response(request) # Apply response middleware for middleware_method in self._response_middleware: response = middleware_method(request, response) response = self.apply_response_fixes(request, response)
get_response() is the part dealing with request/view/exception middleware, and its result is protected by a try...except leading to handle_uncaught_exception() and its email-sending/traceback-display systems.
But why are response middlewares left out of this method, and thus insecurely left without exception catcher ? Shouldn't we simply apply these response middlewares at the same level as others ??
comment:6 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Triage Stage: | Design decision needed → Accepted |
Excellent, thanks B-)
My tests show that if process_request, process_view or process_exception raise an error, normal handling of this error occurs, depending on the "DEBUG" setting : printing full stack information, or sending an email to admins.
But if process_response raises an error, there is visibly no fallback solution : the server simply outputs a raw traceback, and admins are not notified of the error.
Shouldn't the exception management system protect "process_response" too, so that admin notification and the display of a simple "error 500" page occurs ?