id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
9923	Exceptions in middleware loading fail silently	James Aylett	nobody	"If the loading of a piece of middleware fails (either due to failure of the import of the middleware module, or an ImproperlyConfigured exception raised by Django itself), the exception will be pushed up to the handler (wsgi, modpython or whatever), which will generally speaking interpret it as an exception from within *request processing*, rather than framework initialisation. However the handlers simply check that self._response_middleware is not None to decide whether to load middleware, which it will no longer be. So on the *next* request, middleware loading will not be performed, and the request will continue as normal -- but without the failing middleware or any middleware further down the list having been loaded or registered. It's not difficult to imagine security issues coming out of this, although they should only bite in the absence of rigorous testing and review; however it can also cause subtle bugs when dealing with complex middleware which cause considerable pain in development.

One solution would be to ensure that on an exception being raised from within core.handlers.base.BaseHandler.load_middleware() self._response_middleware is set back to None, and the exception logged usefully. This would allow reloading to work.

I've attached a patch which is more aggressive than this: it bombs out (using os._exit) having printed the stack trace. In a development situation this probably doesn't make a huge amount of difference, but it may trigger more obvious warnings in a deployed system. Changing this patch to set self._response_middleware to None would be trivial in any case."		closed	Core (Other)	1.0		invalid		james@…	Accepted	1	0	0	1	0	0