[Django] #30475: Use of i18n_patterns and a buggy 404 template trigger internal server error without a backtrace
Django
without a backtrace
---------------------------------------+------------------------
Reporter: sha-red | Owner: nobody
Type: Bug | Status: new
Component: Core (URLs) | Version: 2.2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
---------------------------------------+------------------------
– Using i18n_patterns with prefix_default_language=True,
– trying to get the frontpage URL without a language given in the URL
works in debug mode, but gives an internal server error without any
backtrace in production mode.
This was caused by a buggy 404.html template, but probably buggy 404
templates should give a backtrace, too, and i18n_patterns shouldn't be
concerned by this anyway.
[draft bug report, I'll try to provide more details later or on request]
--
Ticket URL: <https://code.djangoproject.com/ticket/30475>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
without a backtrace
Reporter: Erik Stein | Owner: nobody
Type: Bug | Status: new
Component: Core (URLs) | Version: 2.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Claude Paroz):
Probably setting up a minimal project to reproduce the issue would be
great.
--
Ticket URL: <https://code.djangoproject.com/ticket/30475#comment:1>
Django
without a backtrace
Reporter: Erik Stein | Owner: nobody
Type: Bug | Status: closed
Component: Core (URLs) | Version: 2.2
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 Carlton Gibson):
* status: new => closed
* resolution: => needsinfo
Comment:
Replying to [ticket:30475 Erik Stein]:
> [draft bug report, I'll try to provide more details later or on request]
Hi Erik.
Happy to look at this but, as Claude says, could you provide a sample
project the reproduces the issue?
What **exactly** is the issue? An error in the 404 template? That i18n
patterns swallows that? (Is it in fact dependent on i18n patterns?) And so
on.
Thanks.
--
Ticket URL: <https://code.djangoproject.com/ticket/30475#comment:2>
Django
without a backtrace
Reporter: Erik Stein | Owner: nobody
Type: Bug | Status: new
Component: Core (URLs) | Version: 2.2
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 Erik Stein):
* status: closed => new
* cc: Erik Stein (added)
* resolution: needsinfo =>
Old description:
> – Using i18n_patterns with prefix_default_language=True,
> – trying to get the frontpage URL without a language given in the URL
>
> works in debug mode, but gives an internal server error without any
> backtrace in production mode.
>
> This was caused by a buggy 404.html template, but probably buggy 404
> templates should give a backtrace, too, and i18n_patterns shouldn't be
> concerned by this anyway.
>
> [draft bug report, I'll try to provide more details later or on request]
New description:
– Using i18n_patterns with prefix_default_language=True,
– trying to get the frontpage URL without a language given in the URL
works in debug mode, but gives an internal server error without any
backtrace in production mode.
This was caused by a buggy 404.html template, but probably buggy 404
templates should give a backtrace, too, and i18n_patterns shouldn't be
concerned by this anyway.
Sample project: https://github.com/sha-red/bugs-django-30475
--
Comment:
I asked about adding a ticket for later reference before posting the issue
and I would consider closing it after two days a bit unfortunate, but I
don't really know your triaging policy, so please forgive me :-).
Today I've added a simple sample project. In a first check it seems that
the Django test client actually deals correctly with the buggy 404
template (delivering a backtrace) making it somehow unuseful in testing
the issue. I added some notes in the README instead.
--
Ticket URL: <https://code.djangoproject.com/ticket/30475#comment:3>
Django
-----------------------------+--------------------------------------
Reporter: Erik Stein | Owner: nobody
Type: Bug | Status: closed
Severity: Normal | Resolution: invalid
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 felixxm):
* status: new => closed
* version: 2.2 => master
* resolution: => invalid
Comment:
Thanks for the sample project. IMO everything works properly. In `DEBUG`
mode Django doesn't use your custom `404.html` page that's why it also
doesn't propagate any errors in this page (you've already described this
as a correct behavior). When `DEBUG=False` Django handles exception by
[https://docs.djangoproject.com/en/stable/ref/urls/#handler500 handler500]
view and logges them in
[https://docs.djangoproject.com/en/stable/topics/logging/#django-request-
logger django.request] logger. If you want to skip this and propagate
exceptions upwards when `DEBUG=False` you can use
[https://docs.djangoproject.com/en/2.2/ref/settings/#debug-propagate-
exceptions DEBUG_PROPAGATE_EXCEPTIONS] setting.
--
Ticket URL: <https://code.djangoproject.com/ticket/30475#comment:4>
Django
-----------------------------+--------------------------------------
Reporter: Erik Stein | Owner: nobody
Type: Bug | Status: new
Component: Core (URLs) | Version: master
Severity: Normal | Resolution:
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 Erik Stein):
* status: closed => new
* resolution: invalid =>
Comment:
Please forgive me for reopening the ticket again!
I guess my original question and reason to open a ticket was that I'm
irritated that i18n_patterns will break in production mode if you have a
buggy 404 template, instead of just redirecting to the correct URL. This
doesn't seem to be correct behaviour in my eyes.
--
Ticket URL: <https://code.djangoproject.com/ticket/30475#comment:5>
Django
-----------------------------+--------------------------------------
Reporter: Erik Stein | Owner: nobody
Type: Bug | Status: closed
Component: Core (URLs) | Version: master
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 Carlton Gibson):
* status: new => closed
* resolution: => invalid
Comment:
Hi Erik.
Sorry for your irritation. I understand these things can be frustrating.
> I don't really know your triaging policy, so please forgive me :-).
See TicketClosingReasons/DontReopenTickets and The
[https://docs.djangoproject.com/en/dev/internals/contributing/triaging-
tickets/#triage-workflow Triage Workflow docs].
Ultimately here I think it's up to the user to ensure their 404 template
loads correctly. That's straight-forward to test. **If** they do introduce
an error, yes we drop right through to the very bottom
`handle_uncaught_exception()` but we know something bad has happened in
that case. As Mariusz points you to, `DEBUG_PROPAGATE_EXCEPTIONS` reveals
the issue immediately.
A custom 404 handler adding logging and/or exception handling around the
`get_template()` call would be possible. But it's unnecessary overhead: a
simple test that the 404.html template does in fact load makes this
unnecessary.
Sorry if that's not what you want to hear.
--
Ticket URL: <https://code.djangoproject.com/ticket/30475#comment:6>