Error page should not invoke callables passed through WSGI META structure

[Eric Buehl]

WSGI servers such as Werkzeug pass callable methods that should NOT be called when the META structure is printed in places such as the debug response handler. ​http://werkzeug.pocoo.org/docs/serving/#shutting-down-the-server

When a Django view throws an error (with DEBUG=True) and is hosted by Werkzeug, it causes the server to silently shut down because the Django error page is blindly calling the shutdown method in order to pretty print the result for the error page.

I have included a pull request that I believe addresses this issue: ​https://github.com/django/django/pull/1546

[Eric Buehl]

Continuation from closed pull request:

There is concern about the performance of looping over the META dict for every request as the patch is currently implemented. As far as I can tell, pep 333 does not make any mention of semantics around passing of callables in the environ dictionary. I agree that this is a bit wonky for Werkzeug to be doing this, but it's unacceptable for Django to be blindly invoking that callable at any point. How about one of the following options:

a) iterate through the META structure only when DEBUG==True
b) delay iteration until we enter the debug handler view

My vote is for option b. Thoughts?

[Aymeric Augustin]

#21345 reports a similar issue for settings.

[Tim Graham]

Yes, adding logic to the debug view as done in #21345 seems okay.

[Arnaud Limbourg]

This is a fairly old ticket and the case can still happen but on the main reasons to use Werkzeug is to have the debugger that comes with it (as is used in django-extensions runserver_plus command). To my knowledge the crash does not happen when using the Werkzeug debugger.

Having callable in request.META seems like a corner case that has limited consequences as it happens in the debug view.

I would set the resolution to won't fix.

[Carlton Gibson]

Yep, OK. Thanks Arnaud.

This is more effort than the fix for #21345, since the META values are not processed in the error reporter but ​in the template. As such we'd need a custom filter (probably replacing the items|dictsort:0 call) adding a do_not_call_in_templates to any callables before entering the loop.

Given that new filters are not often/ever(?) added, and that this has been sat here for four years untouched, and that anyone really needing it is free to adjust the debug template in their own project, I agree with the assessment. (To phrase the other way: even if a PR turned up with such a filter, there'd be a question as to whether it was acceptable...)