Opened 10 years ago

Closed 7 months ago

#22055 closed Cleanup/optimization (wontfix)

404 page does not display stack trace when Resolver404 is raised from a view

Reported by: Grzegorz Nosek Owned by: Andrew Northall
Component: Core (URLs) Version: dev
Severity: Normal Keywords:
Cc: Andrew Northall Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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).

Change History (12)

comment:1 by Grzegorz Nosek, 10 years ago

Owner: changed from nobody to Grzegorz Nosek
Status: newassigned

comment:2 by AeroNotix, 10 years ago

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?

comment:3 by AeroNotix, 10 years ago

Resolution: wontfix
Status: assignedclosed

comment:4 by Grzegorz Nosek, 10 years ago

Resolution: wontfix
Status: closednew

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 a URL from Django core -> no stack trace
  • Raising Http404 from a view -> no stack trace
  • Failing to resolve a URL from a view -> stack trace (and arguably 500 response code but there's backwards compatibility to worry about)
Last edited 7 years ago by Anton Samarchyan (previous) (diff)

comment:5 by Aymeric Augustin, 10 years ago

Triage Stage: UnreviewedAccepted
Type: UncategorizedCleanup/optimization

comment:6 by Mariusz Felisiak, 12 months ago

Owner: Grzegorz Nosek removed
Status: newassigned

comment:7 by Mariusz Felisiak, 12 months ago

Status: assignednew

comment:8 by Andrew Northall, 9 months ago

Status: newassigned

I will work on this.

comment:9 by Andrew Northall, 9 months ago

Cc: Andrew Northall added
Has patch: set
Version: 1.6dev

Initial patch added. Keen for some feedback on the implementation. Many thanks!

https://github.com/django/django/pull/17007

comment:10 by Mariusz Felisiak, 9 months ago

Owner: set to Andrew Northall

comment:11 by Natalia Bidart, 8 months ago

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 PR 17007).

comment:12 by Mariusz Felisiak, 7 months ago

Has patch: unset
Resolution: wontfix
Status: assignedclosed
Triage Stage: AcceptedUnreviewed

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.

Note: See TracTickets for help on using tickets.
Back to Top