Opened 7 years ago
Closed 5 years ago
#29008 closed Bug (fixed)
When DEBUG is True, raising Http404 in a path converter's to_python method does not result in a technical response
Reported by: | Antoine Humeau | Owned by: | Ngalim Siregar |
---|---|---|---|
Component: | Core (URLs) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Herbert Fortes | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
This is the response I get (plain text):
A server error occurred. Please contact the administrator.
I understand a ValueError
should be raised which tells the URL resolver "this path does not match, try next one" but Http404
is what came to my mind intuitively and the error message was not very helpful.
One could also make a point that raising a Http404
should be valid way to tell the resolver "this is indeed the right path but the current parameter value does not match anything so stop what you are doing and let the handler return the 404 page (including a helpful error message when DEBUG is True instead of the default 'Django tried these URL patterns')".
This would prove useful for example to implement a path converter that uses get_object_or_404
.
Change History (12)
comment:1 by , 7 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 7 years ago
The technical_404_response
view performs a new URL resolving (cf https://github.com/django/django/blob/a8e492bc81fca829f5d270e2d57703c02e58701e/django/views/debug.py#L482) which will obviously raise a new Http404
which won't be caught as only Resolver404
is checked. That means the WSGI handler fails and the WSGI server returns the previously described default error message (indeed the error message is the default one from wsgiref.handlers.BaseHandler
https://docs.python.org/3.6/library/wsgiref.html#wsgiref.handlers.BaseHandler.error_body).
The solution seems to be to catch Http404
instead of Resolver404
in technical_404_response
. This will result in a technical 404 page with the Http404
's message displayed and will match the behaviour of when DEBUG
is False
.
comment:3 by , 6 years ago
Cc: | added |
---|
comment:4 by , 5 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:5 by , 5 years ago
Has patch: | set |
---|
Created PR , but I am not sure how to write the tests.
I've looking about the response before and after catch Http404
instead of Resolver404
, and there is no difference. Should I also change the technical_404.html
for response?
comment:6 by , 5 years ago
Needs tests: | set |
---|
comment:7 by , 5 years ago
Needs tests: | unset |
---|
I've added test to the patch, but not sure if it is correct.
comment:8 by , 5 years ago
Needs tests: | set |
---|---|
Patch needs improvement: | set |
comment:9 by , 5 years ago
Needs tests: | unset |
---|---|
Patch needs improvement: | unset |
I have made the requested changes; please review again
comment:10 by , 5 years ago
Needs tests: | set |
---|---|
Patch needs improvement: | set |
Version: | 2.0 → master |
comment:11 by , 5 years ago
Needs tests: | unset |
---|---|
Patch needs improvement: | unset |
Triage Stage: | Accepted → Ready for checkin |
It seems that other exceptions correctly result in a technical 500 response.