[Django] #22055: 404 page does not display stack trace when Resolver404 is raised from a view
Django
view
-------------------------------+--------------------
Reporter: gnosek | Owner: nobody
Type: Uncategorized | Status: new
Component: Core (URLs) | Version: 1.6
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
Related to #18373, the 404 error page served when
django.core.urlresolvers.resolve() fails does not contain the exception
stack trace, which makes finding the failing call unnecessarily difficult.
When the resolve() call fails in a view, the error should actually be 500
(it's not the user's fault), but for backwards compatibility the response
code will have to remain 404 (as discussed with Honza Kral last year).
--
Ticket URL: <https://code.djangoproject.com/ticket/22055>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
view
Reporter: gnosek | Owner: gnosek
Type: Uncategorized | Status: assigned
Component: Core (URLs) | Version: 1.6
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by gnosek):
* owner: nobody => gnosek
* needs_docs: => 0
* status: new => assigned
* needs_tests: => 0
* needs_better_patch: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/22055#comment:1>
Django
view
Reporter: gnosek | Owner: gnosek
Type: Uncategorized | Status: assigned
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by AeroNotix):
Hi,
What kind of useful information could you gain from a 404 page with a
stacktrace? If you're explicitly creating a 404 exception then you want
that to happen.
Could you convince this list of the usefulness in changing this behaviour,
please?
--
Ticket URL: <https://code.djangoproject.com/ticket/22055#comment:2>
Django
view
Reporter: gnosek | Owner: gnosek
Component: Core (URLs) | Version: 1.6
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by AeroNotix):
* status: assigned => closed
* resolution: => wontfix
--
Ticket URL: <https://code.djangoproject.com/ticket/22055#comment:3>
Django
view
Reporter: gnosek | Owner: gnosek
Component: Core (URLs) | Version: 1.6
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by gnosek):
* status: closed => new
* resolution: wontfix =>
Comment:
See #18373 for the use case.
If you're calling resolve('/some-url') that fails, you're not raising an
Http404 explicitly. It's just a function call that fails, just like the
ORM or whatever.
I agree that manually raised Http404s should not trigger the stack trace
and this ticket is not about it. It's just about treating exceptions from
resolve() failure just like every other exception.
IMO, the right thing to do is:
* Failing to resolve an URL from Django core -> no stack trace
* Raising Http404 from a view -> no stack trace
* Failing to resolve an URL from a view -> stack trace (and arguably 500
response code but there's backwards compatibility to worry about)
--
Ticket URL: <https://code.djangoproject.com/ticket/22055#comment:4>
Django
view
Reporter: gnosek | Owner: gnosek
Type: Cleanup/optimization | Status: new
Component: Core (URLs) | Version: 1.6
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by aaugustin):
* type: Uncategorized => Cleanup/optimization
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/22055#comment:5>
Django
view
Reporter: Grzegorz Nosek | Owner: (none)
Type: Cleanup/optimization | Status: assigned
Component: Core (URLs) | Version: 1.6
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* owner: Grzegorz Nosek => (none)
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/22055#comment:6>
Django
view
Reporter: Grzegorz Nosek | Owner: (none)
Component: Core (URLs) | Version: 1.6
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/22055#comment:7>
Django
view
Reporter: Grzegorz Nosek | Owner: (none)
Component: Core (URLs) | Version: 1.6
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Andrew Northall):
* status: new => assigned
Comment:
I will work on this.
--
Ticket URL: <https://code.djangoproject.com/ticket/22055#comment:8>
Django
view
Reporter: Grzegorz Nosek | Owner: (none)
Type: Cleanup/optimization | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Andrew Northall):
* cc: Andrew Northall (added)
* has_patch: 0 => 1
* version: 1.6 => dev
Comment:
Initial patch added. Keen for some feedback on the implementation. Many
thanks!
https://github.com/django/django/pull/17007
--
Ticket URL: <https://code.djangoproject.com/ticket/22055#comment:9>
Django
view
Reporter: Grzegorz Nosek | Owner: Andrew
Type: | Northall
Cleanup/optimization | Status: assigned
Component: Core (URLs) | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* owner: (none) => Andrew Northall
--
Ticket URL: <https://code.djangoproject.com/ticket/22055#comment:10>
Django
view
Reporter: Grzegorz Nosek | Owner: Andrew
Type: | Northall
Cleanup/optimization | Status: assigned
Component: Core (URLs) | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Natalia Bidart):
I'm not sure if it's too late to propose to "unaccept" this ticket. I have
read the use case, and while there is a description for a use case, that
use case feels, to me, insufficient to make a strong argument to add this
change of behavior in the django codebase.
My rationale is that failing to resolve an URL in a view is, indeed,
semantically an "url not found" (404) result. At least in my experience, I
can think of a few reasons for a failed resolve in a view such as:
* there is a spelling error in the url name or args (in which case the
unit tests should caught this)
* there is a dynamic component in the url name/params that at the time
of the execution evaluates to something that does not exist (this still
feels like a 404 and not a 500)
* something else I'm missing?
I don't think the above justify the complexity that seems to be necessary
to solve this (following [https://github.com/django/django/pull/17007 PR
17007]).
--
Ticket URL: <https://code.djangoproject.com/ticket/22055#comment:11>
Django
view
Reporter: Grzegorz Nosek | Owner: Andrew
Type: | Northall
Component: Core (URLs) | Version: dev
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* status: assigned => closed
* has_patch: 1 => 0
* resolution: => wontfix
* stage: Accepted => Unreviewed
Comment:
Agreed, it's not worth adding the extra complexity. 404 is not like other
exceptions and treating some 404s differently just because they don't come
from the Django codebase could be confusing.
--
Ticket URL: <https://code.djangoproject.com/ticket/22055#comment:12>