#30475 closed Bug (invalid)
Use of i18n_patterns and a buggy 404 template trigger internal server error without a backtrace.
Reported by: | Erik Stein | Owned by: | nobody |
---|---|---|---|
Component: | Core (URLs) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Erik Stein | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
– 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
Change History (6)
comment:1 by , 5 years ago
comment:2 by , 5 years ago
Resolution: | → needsinfo |
---|---|
Status: | new → closed |
Replying to 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.
comment:3 by , 5 years ago
Cc: | added |
---|---|
Description: | modified (diff) |
Resolution: | needsinfo |
Status: | closed → new |
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.
comment:4 by , 5 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Summary: | Use of i18n_patterns and a buggy 404 template trigger internal server error without a backtrace → Use of i18n_patterns and a buggy 404 template trigger internal server error without a backtrace. |
Version: | 2.2 → master |
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 handler500 view and logges them in django.request logger. If you want to skip this and propagate exceptions upwards when DEBUG=False
you can use DEBUG_PROPAGATE_EXCEPTIONS setting.
comment:5 by , 5 years ago
Resolution: | invalid |
---|---|
Status: | closed → new |
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.
comment:6 by , 5 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
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 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 redundant.
Sorry if that's not what you want to hear.
Probably setting up a minimal project to reproduce the issue would be great.