[Django] #21048: Error page should not invoke callables passed through WSGI META structure
Django
-------------------------------+--------------------
Reporter: ericbuehl | Owner: nobody
Type: Bug | Status: new
Component: Uncategorized | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
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
--
Ticket URL: <https://code.djangoproject.com/ticket/21048>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: ericbuehl | Owner: nobody
Type: Bug | Status: new
Component: Uncategorized | Version: master
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------+--------------------------------------
Changes (by ericbuehl):
* needs_better_patch: => 0
* needs_tests: => 0
* easy: 0 => 1
* needs_docs: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/21048#comment:1>
Django
Reporter: ericbuehl | Owner: nobody
Type: Bug | Status: new
Component: Uncategorized | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------+------------------------------------
* needs_better_patch: 0 => 1
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/21048#comment:2>
Django
Reporter: ericbuehl | Owner: nobody
Type: Bug | Status: new
Component: Uncategorized | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by ericbuehl):
* easy: 1 => 0
Comment:
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?
--
Ticket URL: <https://code.djangoproject.com/ticket/21048#comment:3>
Django
Reporter: ericbuehl | Owner: nobody
Type: Bug | Status: new
Component: Uncategorized | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by aaugustin):
#21345 reports a similar issue for settings.
--
Ticket URL: <https://code.djangoproject.com/ticket/21048#comment:4>
Django
Reporter: ericbuehl | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timo):
* component: Uncategorized => Core (Other)
--
Ticket URL: <https://code.djangoproject.com/ticket/21048#comment:5>
Django
Reporter: ericbuehl | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
Yes, adding logic to the debug view as done in #21345 seems okay.
--
Ticket URL: <https://code.djangoproject.com/ticket/21048#comment:6>
Django
Reporter: ericbuehl | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* component: Core (Other) => Error reporting
--
Ticket URL: <https://code.djangoproject.com/ticket/21048#comment:7>
Django
Reporter: ericbuehl | Owner: nobody
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by 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`.
--
Ticket URL: <https://code.djangoproject.com/ticket/21048#comment:8>
Django
Reporter: ericbuehl | Owner: nobody
Type: Bug | Status: closed
Component: Error reporting | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* status: new => closed
* resolution: => wontfix
Comment:
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
[https://github.com/django/django/blob/0a01ca80d7f7f1922d0c515669d0e7afd3acff5a/django/views/templates/technical_500.html#L445
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...)
--
Ticket URL: <https://code.djangoproject.com/ticket/21048#comment:9>