Code

Opened 4 years ago

Closed 3 years ago

#13877 closed (fixed)

More documentation needed on exceptions in middlewares

Reported by: pakal <chambon.pascal@…> 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: UI/UX:

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.

Attachments (0)

Change History (6)

comment:1 Changed 4 years ago by pakal <chambon.pascal@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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 ?

comment:2 Changed 4 years ago by gabrielhurley

  • Triage Stage changed from Unreviewed to 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 Changed 4 years ago by pakal

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 Changed 3 years ago by Pakal

  • Component changed from Uncategorized to 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:5 Changed 3 years ago by russellm

@Pakal -- This discrepancy was addressed in r14393.

comment:6 Changed 3 years ago by Pakal

  • Resolution set to fixed
  • Status changed from new to closed
  • Triage Stage changed from Design decision needed to Accepted

Excellent, thanks B-)

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.